Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

A friend once asked me to do some pen-testing on a machine he was running on his home network. He said I'd need to come round to his house to do this as he didn't want to provide access to the machine via the Internet. Fair enough.

When he opened his front door the conversation went something like this:

    Him: "Ah hello, thanks for coming round to do this. It should be fun, come in and we can get started."
    Me: "OK, but I'm already done."
    Him: "What?"
    Me: "I'm done. I've already got root on the machine and I left a little text file in root's home directory as proof."
    Him: "What? But ... what? Wifi?"
    Me: "Nope. Let me in and I'll explain how."
The short story is he had an PoE IP-based intercom system on his front gate. I remembered this from when he was going on about his plans for his home network setup and how amazing PoE was and how he was going to have several cameras etc. I also remember seeing the purple network cable sticking out of the gate pillar whilst the renovation work was being done and the intercom hadn't yet been installed.

I'd arrived 45 minutes early, unscrewed the faceplate of the intercom system and, with a bit of wiggling, I got access to a lovely Cat-5 ethernet jack. Plugging that into my laptop I was able to see his entire home network, the port for the intercom was obviously not on its own VLAN. Finding and rooting the target machine was a different matter but those details are not relevant to this story.

I suppose I got lucky. He could have put the IoT devices on separate VLANs. He could have had some alerting setup so that he'd be notified that the intercom system had suddenly gone offline. He could have limited access to the important internal machines to a known subset of IPs/ports/networks.

He learned about all of the above mitigations that day.

I've always wondered just how many people have exposed their own internal network in a similar way when trying to improve their external security (well, deterrent, not really security) but configuring it poorly.





Not relevant? That’s the best part! Spill it!

enforcing 802.1x on switch is also good solution, especially for "external" ports.

802.1x is quite trivial to bypass if you have an authenticated device (in this case the intercom) that you can transparently bridge[1].

[1]. https://www.defcon.org/images/defcon-19/dc-19-presentations/...


it still will block or slow down many.

802.1x is commonly deployed with macsec. will it be also trivial to bypass ?


Did you ever seen an intercom or IP camera with macsec support?


That's great.

Now we need to get an enterprise grade switch - doubt Cisco would add macsec into SOHO gear. Along with enterprise grade intercoms, cameras, doorbells...

And beloved by many Unifi is out of question - they still can't bake IPv6 support.

So looks like it's feasible but the cost wouldn't be good.

ADD: also read this article: https://news.ycombinator.com/item?id=41531699


i well familiar with macsec. we use it between datacenters and for aws directlink. it de-facto standard for this kind of stuff. i even worked on hardware that provided macsec support

a couple of years ago I tried to use it inside datacenter during fedramp implementation. it crashed and burned for a couple of reasons:

- linux wpa_supplicant was crashing during session establishment

- switch had a limit on number of macsec session per port




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: