Christian Huitema <[email protected]> wrote: > 2) I am not concerned about the disclosure of software vulnerabilities > per software versions, but I am still concerned about the inventory of > devices. Especially if there is an easy way to query devices and find > what software version they are running. Attackers are going to love an > automated way to find out which devices run what vulnerable version.
Let's remember that this is an extension to *MUD* (RFC8520) to embed an SBOM pointer. So in order for a passive attacker to see the pointer, they have *already* seen the pointer to the MUD. To date, MUD doesn't specify a way to load the MUD from the device itself without embedding the IP of the device in the URL. ( https://datatracker.ietf.org/doc/html/draft-jimenez-t2trg-mud-coap-00 proposed a self-reference though) If the MUD file is version of firmware specific, see: https://www.ietf.org/archive/id/draft-ietf-opsawg-mud-acceptable-urls-05.html#name-updating-the-mud-files-in-p for a discussion of when/how one might change the *MUD* URL when the firmware changes) then the attacker does not even need to read the SBOM, or have one present, to know what software version the device is running! If the SBOM is self-hosted, then the device gets to answer correctly about its versioned SBOM. If the SBOM is hosted by the vendor, then the URL in the MUD will need to change when the version changes, and this might mean that the MUD URL also has to change. So what I'm really saying is that the ship has already sailed with RFC8520. An attacker really does not need the SBOM to find out what MUD capable devices are present, and potentially which versions of firmware they are running. It's not trivial to get the MUD URL out of a device though. You can't really just knock. LLDP is pretty hard to do unless you are directly connected at L2 as the switch, but I suppose it might be possible to get it over WiFi. (I never tried) The MUD URL shows up in DHCP requests, and they can be observed when they are broadcast. The IDevID location for MUD URLs is usually only present by observing some TLS (1.2) handshake, perhaps as part of BRSKI. In summary, getting an automated way to find out which devices are vulnerable to attack is going to help the defenders far more than it helps the attackers. But, I did agree that unconfigured devices which have not been onboarded with an administrative credential should not answer queries about their SBOM. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
