OP/bug finder here with some clarifying information. It's a common misconception that this issue can only be abused if you use HTTP boot. That is not the case at all, otherwise it wouldn't be Critical. This bug can be abused locally (privileged malware can overwrite the EFI partition), from an adjacent network if PXE boot is enabled (w/ MiTM), or remotely if HTTP boot is used (w/ MiTM).
More details on these scenarios:
1. A remote attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses HTTP boot. No direct access to the victim machine is required.
2. A remote attacker with privileges and code execution on the victim machine could leverage the issue to bypass Secure Boot, even if the victim does not already use HTTP boot (as long as firmware has HTTP support). How? Several ways:
- An attacker can edit the boot order variable to specify a controlled attacker server.
- An attacker can chain shim->GRUB2->shim (via HTTP). For this technique, an attacker would overwrite the boot loader in the EFI partition to a legitimate shim and GRUB2 image. The attacker would create a grub.cfg that chainloads a new shim via HTTP. This is possible because GRUB2's device syntax allows you to specify any supported device, including HTTP (if available).
3. An adjacent attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses PXE boot. PXE is separate from HTTP boot, but similar to the local vector, an attacker can chain together shim (via PXE)->GRUB2 (via PXE)->shim (via HTTP).
I can assure you the answer clicked before my research ever started. Unless I am using web server software that responds with one site for multiple host names, you generally need to configure each host name that might be used with your web server as a different "site" (i.e Apache) / configuration. I could have simply edited my hosts file with hidusi[.]com pointing to my web server and created a separate site configuration to serve the hidusi[.]com domain with the second stage. What I was saying in my last response was that instead of using my hosts and having to create this new site configuration (or modify existing with an alias), I could just swap out the domain in the document and use my web server's current state without any additional modification required. It was simply more convenient to change a single domain rather than update my web server's configuration to support requests for the hidusi[.]com alias. There is no significance to using the original domain for serving the second stage, I think you all are all just overthinking it :)
Yes, but at the time I already had an existing domain with a web server I could use. You are correct that I could have setup a separate site for hidusi[.]com and then point the domain directly at my web server's IP, but since I already had a domain/web server configured, it was much easier just to swap the domain in the document.
Author here. Yes simply editing my hosts file would have been much easier. The reason I went the longer approach of setting up the payload on a remote web server was because there is the concept of security zones in Internet Explorer. Visiting localhost in Internet Explorer gets treated with a different level of trust compared to randomwebsite.com. For example, if you go to your security settings in Internet Explorer, there is an "Internet" zone but also a "Local intranet" zone. If you compare the two, you'll see they have different security settings. By hosting the payload on an external domain, we ensure that we are simulating an identical environment that existed for the attack (and are not subject to a different level of trust).
Dell SupportAssist comes pre-installed on most new Dell machines. The only reason it wasn't installed on my machine is because the drive I used was not prepared by Dell. Your average Dell user will have SupportAssist installed though you are right that it can be uninstalled.
There were a bunch of ways to bypass the check. For example another way would be to use "http:\\" which wouldn't get detected either. The new version isn't vulnerable.
More details on these scenarios:
1. A remote attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses HTTP boot. No direct access to the victim machine is required.
2. A remote attacker with privileges and code execution on the victim machine could leverage the issue to bypass Secure Boot, even if the victim does not already use HTTP boot (as long as firmware has HTTP support). How? Several ways:
3. An adjacent attacker with no privileges in a man-in-the-middle (MitM) position could leverage the issue against a victim machine that uses PXE boot. PXE is separate from HTTP boot, but similar to the local vector, an attacker can chain together shim (via PXE)->GRUB2 (via PXE)->shim (via HTTP).