[HN Gopher] Ghost in the ethernet optic
___________________________________________________________________
Ghost in the ethernet optic
Author : rcarmo
Score : 202 points
Date : 2022-01-13 12:02 UTC (10 hours ago)
(HTM) web link (blog.benjojo.co.uk)
(TXT) w3m dump (blog.benjojo.co.uk)
| pabs3 wrote:
| I wonder if it is GPL compliant, including the ability to update
| the Linux kernel/etc.
| iso1631 wrote:
| There's no requirement in GPL 2 (the one the kernel uses) to be
| able to update the kernel.
| NavinF wrote:
| I was about to say the same thing, but I think he's talking
| about how GPL2 requires the company to give OP the kernel
| source code. OP mentioned that he didn't have the kernel
| headers for DKMS.
| iso1631 wrote:
| Ah sure, if it's not a stock kernel then yes you'd need to
| distribute the code for it (although there's no requirement
| for it to be able boot from any replacement kernel you
| provide)
| simiones wrote:
| This is debatable - the license is pretty clear about it
| being a requirement, but it has been patchily enforced:
|
| > The source code for a work means the preferred form of the
| work for making modifications to it. For an executable work,
| complete source code means all the source code for all
| modules it contains, plus any associated interface definition
| files, plus the scripts used to control compilation and
| _installation of the executable_ [emphasis mine].
|
| Even in the infamous TiVo case, customers of TiVo had
| complete access to modify the Linux kernel or any other GPL
| binary - the proprietary TiVo software would just refuse to
| run if any modification had been applied this way.
| iso1631 wrote:
| Yes, there's no requirement for the sfp to boot any
| specific kernel, thus no requirement
|
| "to update the Linux kernel/etc"
|
| If they aren't using a stock kernel with drivers already in
| the kernel, then clearly they have to distribute that code
| (which might just be a shim like with nvidea), but not boot
| from it -- it's not GPL3
| kloch wrote:
| There are two main uses for this kind of thing.
|
| - Legit: debugging/monitoring. Other legit uses are theoretically
| possible but the device has severe limitations that likely make
| them impractical or unwise.
|
| - Surreptitious: This is clearly where the value proposition of
| this device lies. An optic could be "unknowingly" swapped out on
| an interesting link to snoop on or infiltrate a network.
|
| Swapping out optics in a large network is not uncommon as they do
| fail. More often they are swapped out as a troubleshooting step
| where the original optic may not even be bad. This way log
| messages indicating link flap and replacement of an optic could
| likely go unnoticed.
| NavinF wrote:
| Ehh this chonker doesn't look very surreptitious. I can only
| think of one other device that sticks out even further in front
| of the switch. Said device is a very old SFP+ to 10G 100m
| copper module with a huge heatsink and an external power brick!
|
| That aside, I could imagine a gov't agency programming these
| things and forcing ISPs to put them on customer ports. No need
| to wait for a maintenance window or free up rack space.
| kloch wrote:
| This is one reason why I am a big proponent of network
| engineers physically visiting their equipment periodically.
| In large networks that may never happen, data center techs
| (often not even your own employees) are the only ones who
| ever see the racks in person.
|
| Even if the 3rd party tech notices something unusual about
| the optic the certainly aren't going to touch it without a
| ticket and will probably not even mention it.
| formerly_proven wrote:
| Looking at the pictures this thing isn't exactly the typical
| SFP form factor, it protrudes ~5 cm or so over a normal SFP. So
| if you swap one of these out it's going to stick out like the
| proverbial sore thumb.
| benjojo12 wrote:
| Who says you can see the side they swapped the optic on? For
| datacenter cross connect links, its not uncommon for the
| other side of the link to be somewhere you can't see/have
| access to.
| formerly_proven wrote:
| That's a fair point though in that case someone with
| physical access can do essentially anything with the cable
| anyway - this "just" makes it easier.
| jauer wrote:
| Things like this have been around for nearly (at least?) 10
| years, but are not well-known outside of spaces that care about
| telco-style demarc & OAM systems.
|
| An example from ~2012 would be the RAD MiNID which is available
| in a handy "sleeve" format where you can use your normal SFP with
| the smart SFP.
|
| Pretty cool to see a writeup of this sort of thing (and increased
| vendor representation).
| w7 wrote:
| Last year on another transceiver (QSFP28) teardown[0] I was
| surprised to find out that transceivers not marketed as "smart"
| also have SOCs inside them to regulate internal temperature. I
| had always thought the devices were "dumber" and never bothered
| to look inside.
|
| So programmable CPUs in your transceivers might be more common
| than one would think.
|
| [0] https://twitter.com/kwf/status/1470508119725805570
| mmastrac wrote:
| While researching EEPROM flashing on AliExpress SFPs, I
| discovered that many of these do support SSH. I suspect that even
| the smaller ones might have tiny Linux onboard.
|
| Example:
|
| https://forum.mikrotik.com/viewtopic.php?t=116346
|
| https://github.com/hwti/G-010S-A
| KennyBlanken wrote:
| elithrar wrote:
| RE: intelligence agencies -
| https://twitter.com/wingarscarlett/status/148160261830488883...
|
| One of the replies to Ben's tweet includes a diagram and
| references to the NSA's RJ-45+Ethernet capturing device within
| the RJ-45 jack itself.
| kazen44 wrote:
| we can assume this also exists in SFP devices aswell. SFP's
| are relatively simple devices with room to spare, especially
| for a nation-state actor.
|
| The issue is this is completely undetectable.
| colonwqbang wrote:
| In the article he describes the device as "terrifying" and
| "cursed". I think he gets it.
| teddyh wrote:
| jgrahamc wrote:
| Ben and I worked together. He's very smart and fully
| understands the implications; he's also British and so
| understatement is natural for him.
| teddyh wrote:
| In that case, I simply wish that he would adapt his style
| to suit his, presumably mostly non-British, audience.
| jgrahamc wrote:
| I don't. What a sad world that would be.
| benjojo12 wrote:
| Mono-cultures are bad! I'm British. The blog is my blog,
| not a corporate blog.
|
| I think it's fair for my own content to genuinely be me.
| teddyh wrote:
| Cultural differences sometimes lead to misunderstandings.
| Like in this case, where I assumed, incorrectly, that you
| were being deliberately coy. If you want to keep your own
| personal style, please do, but be advised that your
| language is not the universal language, and if you wish
| to have an international audience and be understood by
| most of them, a little bit of adaptation goes a long way.
| mmastrac wrote:
| The world doesn't exist for your personal style. Enjoy
| the variety.
|
| I quite enjoyed it.
| lexicality wrote:
| Ben is British, as per English Understatement[1] "a bit
| terrifying" is a major statement of alarm and "immensely
| cursed" means "I sure am glad I don't have to do hardware
| security"
|
| [1]: https://en.wikipedia.org/wiki/English_understatement
| buro9 wrote:
| Ben is being witty... he certainly is very aware of the
| possible uses of this piece of hardware, and he's also
| intellectually curious about how to take advantage of cheap
| hardware interesting ways (and network protocols, etc). The
| rest of his blog should hint at this depth, but he's just
| light-hearted, curious and fun with this stuff. Bear in mind he
| brought us BGP Battleship https://blog.benjojo.co.uk/post/bgp-
| battleships and runs his own AS (because you can!).
| ralferoo wrote:
| Also, the screenshot makes it pretty clear he's aware of the
| risk of this device.
|
| https://blog.benjojo.co.uk/asset/xaTe0Gf3Az
| snickmy wrote:
| (random thought) It surprises me how, despite working in the tech
| industry for over a 15 years now, I struggled in following the
| details of this blog post (which is well written). It's so
| impressive how things got very complex over time, and how
| verticalize the role of an Engineer is becoming.
| NavinF wrote:
| I feel like things have gotten a lot simpler over time.
| Examples:
|
| 1. There's only one relevant type of optics (Q)SFP(+)(28)
| instead of many incompatible ones. Line cards have become
| uncommon.
|
| 2. Everything runs Linux so he can just run tcpdump instead of
| some vendor specific monitor command.
|
| 3. 10G ethernet and 56G infiniband are dirt cheap so now
| there's a large online community for homelabs that use data
| center hardware. Nobody needs to be a network guy to run a data
| center.
| kazen44 wrote:
| > Nobody needs to be a network guy to run a data center.
|
| the complexity from networking at a DC mainly comes from
| scale.
|
| running enterprsie/dc hardware in a homelab is vastly
| different from running it in production.
| hansel_der wrote:
| your argument seems to hinge on the perspective on "scale"
|
| i.e. enthusiast homelabs from today have sufficient
| capacity/performance to accomodate production scenarios
| ("at scale") from 20y ago.
|
| besides the need for appreciation of ones work, everybody,
| all the time, is cooking with water.
| kazen44 wrote:
| what i actually meant to say was that multitenancy makes
| networking complex. (and nearly any network is multi-
| tenant once it reaches a certain scale).
|
| Also, depending on the services which run on the network,
| more complex technology like MPLS/VXLAN-EVPN is needed.
| ghosty141 wrote:
| >running enterprsie/dc hardware in a homelab is vastly
| different from running it in production.
|
| This applies to all of software. Enterprise and "home"
| diverged quite a lot. Back in the 2000s running a webserver
| at home was roughly similar to doing it for a company.
| Nowadays they are nothing alike with all the load
| balancing, caching etc. etc.
| iso1631 wrote:
| Not all companies are running webservers that need
| caching and load balancing. Most people aren't google.
| 3np wrote:
| Conversely, if you're the kind of person who by nature
| enjoys to overengineer and are doing hosting for fun...
| CountDrewku wrote:
| Yeah I feel like this would be mostly used for nefarious purposes
| since it wouldn't be obvious it was there. Other than that I
| can't think of any way that it's better than just a raspberry pi.
| NavinF wrote:
| Fascinating! Tho I can't think of that many use cases where a 1G
| hub and raspberry pi can't do the job.
| ale42 wrote:
| This seems so nice for NSA-like implants...
| sneak wrote:
| I think those are designed to avoid detection, so they (having
| near-unlimited budgets for these sorts of covert things) prefer
| to go with replacement firmwares and suchlike. They've been
| known to intercept packages of networking equipment and do all-
| software implants so that you can't even tell a device has been
| tampered by looking at it, and if they want to exit they can
| remove all traces that they were there. Leaving physical
| hardware in place is the opposite of that.
|
| There are _so many_ places to hide malicious code in any
| computer or networking system these days, using weird
| nonstandard obvious hardware like this is pretty amateur.
| userbinator wrote:
| What caught my eye was the pixelated serial numbers. Also, the
| fact that the part and serial numbers are plainly visible in a
| few pictures, but not others.
| benjojo12 wrote:
| Where can you see serial numbers? I thought I got them all
| jaywalk wrote:
| The first three pics. I only see pic where it's censored.
| benjojo12 wrote:
| Oh huh! Oh well. My main effort was to conceal the MAC's
| rytill wrote:
| He said
|
| > But such a feature could also be used to create a fake
| 169.254.169.254 (AWS/Cloud metadata IP address endpoint) and
| serve requests from it.
|
| Wouldn't such a thing be impossible if the application is using
| end-to-end encrypted requests to AWS?
| optimuspaul wrote:
| the metadata service is http and not encrypted.
| ptsneves wrote:
| I am surprised they used debian and not Yocto or buildroot, for
| an embedded device. Would anyone speculate on why debian would be
| preferred?
| mschuster91 wrote:
| I've had to work with embedded devices in the past (develop an
| alternative firmware for $THING), and irgh I hated buildroot
| which was the original firmware's base. Way too much effort to
| compile stuff yourself... a simple "debootstrap" and
| installation of your private packages is way easier to get
| stuff up and running. And when you run into some package you
| need, you directly run "apt install" on the device itself, add
| the install command to the script that creates your firmware
| image and that's it.
|
| The best thing is, whatever issues you run into will already
| have been solved a million times before by the wide Debian
| community and whatever remains can be solved by a quick hop
| into #debian on whatever IRC network they migrated to.
| benjojo12 wrote:
| (Author of post)
|
| They advertise this as a network appliance, so it makes sense
| that they use Debian since being able to install packages via
| things like apt makes the whole experience much easier. A lot
| of career network engineers are not that savvy with sysadmin
| type roles, so something like buildroot would alienate their
| market a little
| imachine1980_ wrote:
| ARMv7, with 512M of RAM, isn't that embbeded and you win a full
| os whit ready to use tested packages, package managers, and
| boot system, it saves a lot of times and expertice, maybe they
| need to opt out of it if they want to have better termals, or
| more optimization.
| phoronixrly wrote:
| I find this very interesting. Most of my concerns with using this
| would be alleviated if I was able to flash my own image onto the
| SFP, e.g. an OpenWrt installation. (Disclaimer: no offence to the
| people that produce this product, I'm an equal opportunity closed
| source firmware avoider:)
|
| The author mentions that 'In a more premium software package for
| the smart-sfp you can configure ERSPAN sessions with filters'.
| Selling a more expensive software package for the SFP would be a
| reason to lock it down and prevent others from offering competing
| (including open-source) software.
|
| Another interesting aspect is the communication with the
| programmable logic. What is implemented in the FPGA? Is it purely
| signal processing? Is there packet inspection and filtering?
| Could the communication between the CPU and the FPGA be reverse
| engineered to provide a driver?
|
| Edit: Ben, do you plan on playing around some more with these to
| find out if they can be hacked to run your own OS?
| benjojo12 wrote:
| > Ben, do you plan on playing around some more with these to
| find out if they can be hacked to run your own OS?
|
| Nope, I'm probably going to use it as a remote monitoring/out
| of band device when the time comes. The device is useful enough
| in it's slightly closed source state than as a device for
| hacking (and maybe a bricking risk)
| winniejinping wrote:
| Also there are SFP ONU modules for GPON/EPON, I've been using one
| (with RTL9601C chipset) for a year and it works great, fiber
| cable directly to the router or switch, no more shitty ISP ONU &
| router.
___________________________________________________________________
(page generated 2022-01-13 23:01 UTC)