This is a hard question to answer (absolutely). While the NUC BIOSs are hardened to prevent writes to the firmware code sections of the flash, there are new exploits being developed all the time. Are you sure this taint isn't attaching to/through the HDD/SSD?
I am also concerned about the SSD as well, but I believe in one instance I was able to get a clean install of Debian which then afterwards became penetrated after a USB from a compromised machine was inserted and I pulled critical files off of it. I ejected the USB and then got a suspicious message saying "Please wait while files are being written to the USB device" but I had only read from the USB device. So the USB must have still been furiously trying to complete it's attack and was asking for more time from the user. Using a cheap USB with very low speed read/write times makes this obvious. I knew the source NUC for the files was compromised and this was intended to be a one time use, throw away USB stick. I also had been noticing extremely excessive USB I/O LED activity when the device should have been idle in the past with a number of other USB sticks. Ultimately they infected a USB stick I was using to install Debian. This attack vector resulted was an fresh OS install with a compromised version of passwd that stole my root passwords and was doing other stuff at the same time. more on that later if you are interested.
But was that USB stick being infected by software on the originating infected NUC or by the firmware controlling the USB port on the infected machine ?
The device in question is a 5i3RYH
date of manufacture 03/2015
"made in china"
G6RY11006PD SA H41220-102
Naturally my other concerns are; is the malware writing to the SSD bios and is the malware attacking the NUC bios to enable KVM there. Because in another infected NUC I get a syslog message stating "KVM is disabled by bios"
The end result is this malware creates remote VNC or X11 sessions elsewhere on the attackers machine which are mirror images of my desktop. I know this because my banking site was able to detect a concurrent session and that is causing me a big problem. I've since disabled remote sessions via config files and on my firewall as best I can. though it is unknown if this is working. I will need to create a snort filter on my LAN interface at the firewall to check for these specific packets yet.
Which then raises yet another HUGE concern which is; are they activating a VNC session embedded in the BIOS (which I have updated to the most recent). Even though I don't have a VPRO edition NUC ? Is VPRO wittren into all BIOSes and just simply disabled if the product isn't being sold with that as a feature ? With BIOS returning a message saying KVM disabled, that sure indicates it is.
They also broke into my newegg acount and saw this device was a recent purchase so I believe the attack has been directly tailored for this specific machine.
Another concern is the persistence of iscsi configurations showing up in BIOS config ? where are these originating from ? Does bios create them ? How do I remove them ?
I think these are another part of the attack package.
How secure are the BIOS flags bits from the OS ?
These questions are beyond me. I have forwarded this to one of Intel's BIOS Security experts. I will let you know what he has to say (it may take a few days for him to respond)...
OK my mistake here - the kernel error message "
kernel: [ 3.412261] kvm: disabled by bios
actually refers to Intel Virtual Technology which I do have disabled in BIOS - not to Intel VPro which is advertised as not present on this device. So this syslog message is valid.
But my question remains is any aspect of VPro in BIOS but not referenced in the BIOS GUI - Specifically VNC -
Because my vulnerability was unauthorized remote desktop sessions. Eith in the form of X11 or VNC I don't know which. I have disabled X11 in my OS config files - but VNC sessions created by the BIOS would be beyond my control.
One thing is certain this NUC was very heavily compromised and if Intel is interested in having it shipped to them for firmware and bios breaches I would be most happy to do so.
Of particular concern to me as well is the iscsi configurations which have appeared in bios that I did not create. re-installing the O/S to a reformatted has not cleared them.