Added capability to audit ESP partition for revoked files#24
Added capability to audit ESP partition for revoked files#24sei-vsarvepalli wants to merge 15 commits intocjee21:mainfrom
Conversation
|
Some questions/issues:
Suggestion:
|
I think my script was meant to use Authenticode hash only and ignore the flat hash.
Sure will add it in a couple of days.
Ok can update that.
Agreed.
👀 - looking.. |
But it doesn't and is the opposite... function Get-FileSha256Hex {
param([Parameter(Mandatory)][string] $FilePath)
(Get-FileHash -Algorithm SHA256 -LiteralPath $FilePath).Hash.ToUpperInvariant()
}# We put it in same set for now; the caller will label which “kind” matched.
# Without computing authenticode hashes locally, only flatHash matches are actionable.
[void]$sha256Set.Add($img.authenticodeHash.Trim().ToUpperInvariant())# Hash match
if ($fileSha -and $set.Sha256Set.Contains($fileSha)) {
$matches += [PSCustomObject]@{ Source=$set.Name; Type='Hash'; Detail='SHA256(flat) matches revocation list' }
} |
|
okay looking at fixing that. I think my Get-AuthenticodeHash code is broken! so perhaps settled for the direct sha256 when available. It should definitely move away from that. If you have or aware of a readily available PowerShell for getting AuthenticodeHash lmk. |
--> 71dae46 and I see you are using |
6f893f2 to
33059e1
Compare
Thanks - that helps a lot. My code for Authenticode Signatures was very buggy. This seems to work fine. I have also added the example for scanning a CD rom like D:\ |
|
Good news is that it does detect revoked shim from Canonical now: |
Should be resolved. |
| } | ||
|
|
||
| # MSFT JSON does not directly provide DER blobs for revoked cert entries (at least in the snippet provided), | ||
| # so in MsftJson mode we can only do hash-based checks unless you add a mapping of signer certs separately. |
| $sigs = Get-EfiSignatures -FilePath $file | ||
| $fileSha = $sigs.Authentihash | ||
| foreach ($sig in $sigs.Signatures) { | ||
| foreach ($c in $sig.Certificates) { |
| $matches += [PSCustomObject]@{ Source=$set.Name; Type='Hash'; Detail='SHA256(Authenticode) matches revocation list' } | ||
| } | ||
|
|
||
| # Cert match (only meaningful for CurrentDbx unless you add cert data to MsftJson mode) |
README.md
Outdated
|
|
||
| [!WARNING] | ||
| Detection is based on hash and certificate matching only. | ||
| Newer revocations using **SVN (version-based enforcement)** are **not currently checked**. However `Check EFI file info.cmd` will display SVN/SBAT data if present, but this tool does not compare it against UEFI NVRAM policy. Support for SVN comparison is welcome as a feature request. The `Check EFI file info.cmd` also provides SBAT information. The SBAT enforcement is handled by shim, this tool will likely catch revoked shim binaries. |
There was a problem hiding this comment.
The SBAT enforcement is handled by shim, this tool will likely catch revoked shim binaries.
I do not think it will catch newer revoked shims as those are only revoked using SBAT. Same with Microsoft's Boot Managers that now use SVN to revoke.
There was a problem hiding this comment.
Example of shim revoked with SBAT: https://launchpad.net/~canonical-signing/+archive/ubuntu/primary-2022v1/+build/26761603/+files/shim-signed_1.56+15.7-0ubuntu1_amd64.deb
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,3,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.ubuntu,1,Ubuntu,shim,15.7-0ubuntu1,https://www.ubuntu.com/
SBAT is now shim,4
There was a problem hiding this comment.
I will do a push to say SBAT feature is also missing. The shim self test you mention is a specific rollback prevention revocation. Also the newer shims (specifically 15.7 and later, including 15.8+), SBATLevel NVRAM variable is actually now visible in the Operating System and there is also arguable SBATLevelRT visible in the UEFI NVRAM Runtime services in the in-between shim versions, too.
There was a problem hiding this comment.
They are using SBAT to revoke Shim and Grub and SVN to revoke Windows Boot Manager now instead of using DBX hash. That's the reason they invented SBAT and SVN, to reduce NVRAM usage. SBATLevelRT is a volatile variable created by Shim at boot. It is only available when booting from Shim. Not available on Windows. Windows only writes the SBATLevel variable to revoke vulnerable Shim and Grub.
|
It works fine now. Just some minor touch-up needed. |
This setup now has an audit capability to check if any of the EFI files in the ESP folder - (default ESP mapped as FS0) has any files that are matching with the file in the DBX. Just right click "Scan EFI file against Microsoft DBX JSON".
The script can be used to audit current DBX status before applying the DBX update.
See screenshot example