5 ms·

HTTP, and no check of the executable signature. I'd say the latter is the worse offence, but the two flaws really come together to provide an excellent MitM vec

HTTP, and no check of the executable signature. I'd say the latter is the worse offence, but the two flaws really come together to provide an excellent MitM vector.

ajross 3y ago
Is that part verified? The linked article doesn't say, and the Eclypsium blog post isn't really clear either. What they say is that the motherboard firmware is causing the resulting windows boot process to run code provided by the firmware (which is weird, but not insecure per se), and that this code is delivered over HTTP. They notably aren't saying that the firmware or loader is doing no validation on the executable. Most likely this has some sort of home grown signature on the blob, because if it didn't they instantly would have cooked up a MitM exploit to demonstrate. The fact that they didn't implies that it doesn't work. That's not to say this is a good design (it's clearly not) or that it can't be abused in non-malware ways (junkware, etc...). But it does seem like it's being spun as a clear security hole when my guess is that it isn't (it certainly hasn't been shown to be).
- NohatCoder 3y ago
  >> What they say is that the motherboard firmware is causing the resulting windows boot process to run code provided by the firmware (which is weird, but not insecure per se), and that this code is delivered over HTTP. No, the firmware copies a program from itself to Windows, that program then downloads and executes another program from the internet, without verifying it correctly. Article says: "The firmware does not implement any cryptographic digital signature verification or any other validation over the executables." So unless that is downright wrong the MitM path is wide open. There is a signature check built into Windows, but way too much stuff has been signed to make that a meaningful barrier.
- jeroenhd 3y ago
  The Eclypsium blog post does state the following: "The firmware does not implement any cryptographic digital signature verification or any other validation over the executables." Unless your Windows was configured to only run signed software or Gigabyte would apply the Mark of the Web to these files (which would make it harder for them to run their own update process), the executable file downloaded and run as a service doesn't seem to get checked. As far as I can make out from the blog post, a MitM attack during the motherboard update process would allow for the motherboard to be flashed with malicious software which in turn would indeed allow for dropping Windows executables onto the system. Luckily, barely anyone uses the built-in online updater for their motherboards. The https://software-nas/Swhttp/LiveUpdate4 https://software-nas/Swhttp/LiveUpdate4 URL is a pretty potential risk. You don't even need MitM to pretend to be that URL as it's not a FQDN. If there's any kind of HTTPS certificate validation that URL seems pretty useless in general. Maybe it's some kind of internal testing server that made it into production?

HTTP, and no check of the executable signature. I'd say the latter is the worse offence, but the two flaws really come together to provide an excellent MitM vector.

ajross 3y ago

Is that part verified? The linked article doesn't say, and the Eclypsium blog post isn't really clear either. What they say is that the motherboard firmware is causing the resulting windows boot process to run code provided by the firmware (which is weird, but not insecure per se), and that this code is delivered over HTTP. They notably aren't saying that the firmware or loader is doing no validation on the executable. Most likely this has some sort of home grown signature on the blob, because if it didn't they instantly would have cooked up a MitM exploit to demonstrate. The fact that they didn't implies that it doesn't work. That's not to say this is a good design (it's clearly not) or that it can't be abused in non-malware ways (junkware, etc...). But it does seem like it's being spun as a clear security hole when my guess is that it isn't (it certainly hasn't been shown to be).

NohatCoder 3y ago
>> What they say is that the motherboard firmware is causing the resulting windows boot process to run code provided by the firmware (which is weird, but not insecure per se), and that this code is delivered over HTTP. No, the firmware copies a program from itself to Windows, that program then downloads and executes another program from the internet, without verifying it correctly. Article says: "The firmware does not implement any cryptographic digital signature verification or any other validation over the executables." So unless that is downright wrong the MitM path is wide open. There is a signature check built into Windows, but way too much stuff has been signed to make that a meaningful barrier.
jeroenhd 3y ago
The Eclypsium blog post does state the following: "The firmware does not implement any cryptographic digital signature verification or any other validation over the executables." Unless your Windows was configured to only run signed software or Gigabyte would apply the Mark of the Web to these files (which would make it harder for them to run their own update process), the executable file downloaded and run as a service doesn't seem to get checked. As far as I can make out from the blog post, a MitM attack during the motherboard update process would allow for the motherboard to be flashed with malicious software which in turn would indeed allow for dropping Windows executables onto the system. Luckily, barely anyone uses the built-in online updater for their motherboards. The https://software-nas/Swhttp/LiveUpdate4 https://software-nas/Swhttp/LiveUpdate4 URL is a pretty potential risk. You don't even need MitM to pretend to be that URL as it's not a FQDN. If there's any kind of HTTPS certificate validation that URL seems pretty useless in general. Maybe it's some kind of internal testing server that made it into production?