###### tags: `finished`
:::success
# SSN Lab 2 - UEFI Secure Boot
:::
## Task 1 - Firmware Databases
:::info
1. Extract the Microsoft certificate that belongs to the key referred to in Step 1 from the UEFI firmware, and show its text representation.
:::
If we are talking about the certificate that is in KEK, then it looks like this.
<center>
Figure 1 - Certificate
</center>
:::info
2. Is this certificate the root certificate in the chain of trust? What is the role of the Platform Key (PK) and other variables?
:::
Thanks to your comment, I now understand that the answer to this question is no, this certificate is not a root certificate.
PK is the platform key, which is embedded in the firmware by the platform manufacturer and is the root of trust. Trusted operating system vendors and others are documented by signing their keys with a platform key.
PK is used to manage the KEK keystore, or rather to update it. Each KEK key establishes a connection between the manufacturer of the executable component and the embedded software. These keys are used to manage the db repositories (here are certificates and hashes of components allowed to run) and dbx (here are certificates and hashes of components that need to be banned from running).
## Task 2 - SHIM
:::info
3. Verify that the system indeed boots the shim boot loader in the first stage. What is the full path name of this boot loader?
:::
Since secure boot is enabled, we only see one entry:
<center>
Figure 2 - Boot loader
</center>
:::info
4. Verify that the shim bootloader is indeed signed with the “Microsoft Corporation UEFI CA” key.
:::
The `sbverify --list` command outputs a list of all signatures.
<center>
Figure 3 - Signiture
</center>
And to verify the certificate, we will extract it from the system. First you need to get the keys from the signature database using `mokutil --export --db`.
<center>
Figure 4 - Keys
</center>
Then I converted the keys to .pem format using the following command for all:
`openssl x509 -inform der -outform pem -in DB-0001.der -out DB-0001.pem`
After I found the right certificate, it turned out to be DB-0001.pem
<center>
Figure 5 - Lists of certs
</center>
Let's check it out:
<center>
Figure 5 - Verification
</center>
:::info
5. What is the exact name of the part of the binary where the actual signature is stored?
:::
Authenticode signatures can be located in a Windows PE file, in a location specified by the Certificate Table entry in Optional Header Data Directories.
After the MS-DOS stub (at location 0x3c, the stub has the file offset to the PE signature), at the file offset specified at offset 0x3c, is a 4-byte signature that identifies the file as a PE format image file. This signature is "PE\0\0" (the letters "P" and "E" followed by two null bytes).
:::info
6. In what standard cryptographic format is the signature data stored?
:::
In PKCS#7:
> A PKCS #7 SignedData structure contains the PE file's hash value, a signature created by the software publisher’s private key, and the X.509 v3 certificates that bind the software publisher’s signing key to a legal entity.
:::info
7. Extract the signature data from the shim binary using dd. Add 8 bytes to the location as given in the data directory to skip over the Microsoft WIN CERTIFICAT structure header (see page 14 of the specification if you are interested).
:::
<center>
Figure 4 - Inside shimx64.efi
</center>
Okay, after checking the comment, I asked the other students how they performed this task. One option was to use pyew for Python2, let's try it.
Pyew installation:
```
#get a repository
git clone https://github.com/joxeankoret/pyew.git.
#install Python2
sudo apt-get install Phyton2
#install pip
curl https://bootstrap.pypa.io/pip/2.7/get-pip.py --output get-pip.py
sudo python2 get-pip.py
#modul capstone for pyew
sudo python2 -m pip install capstone
```
<center>
Figure 5 - Pyew's work
</center>
Now let's look at all the entries in the directory:
<center>
Figure 6 - List of entries
</center>
> <Structure: [IMAGE_DIRECTORY_ENTRY_SECURITY] 0x128 0x0 VirtualAddress: 0xE73C8 0x12C 0x4 Size: 0x2140>
This is what we need because it points to the Certificate Table.
Now for virtual address **0xE73C8** = 947144; Microsoft WIN certificate structure header is 8 , we need to skip it - 947144 + 8 = 947152.
And for size **0x2140** = 8512; the same 8512 - 8 = 8504 bytes.
I used the following command to extract the signature data from the shim binary file.
```
sudo dd if=/boot/efi/EFI/ubuntu/shimx64.efi bs=1 count=8504 skip=947152 > signature
```
<center>
Figure 7 - recording a signature using dd
Figure 8 - iside file with signature
</center>
:::info
8. Show the subject and issuer of all X.509 certificates stored in the signature data.
Draw a diagram relating these certificates to the “Microsoft Corporation UEFI CA”
certificate.
:::
<center>
Figure 9 - Diagram
</center>
Okay, I have a general picture of the relationships, now let's go back to the certificates of the dedicated section.
If you decrypt the file, you will find familiar certificates inside. Now it remains only to link them together. Third-party boot loaders currently do not have access to the Microsoft Windows Production PCA 2011 certificate Microsoft uses for their own products. Instead, Microsoft provides a signing service originally intended for UEFI drivers. This service has been extended to include third-party boot loaders, too. Microsoft reviews the submitted UEFI applications, provides an AuthentiCode signature using its own key, and sends the result back to the author. This signature does not identify the application author (it is pseudonymous), and, more importantly, it is chained via the intermediate certificate Microsoft Corporation UEFI CA 2011 to the Microsoft Corporation Third Party Marketplace Root root certificate. And Microsoft Windows UEFI Driver Publisher for third-party drivers.
<center>
Figure 10 - MC UEFI CA
</center>
> Certificate:
Data:
Version: 3 (0x2)
Serial Number:
61:08:d3:c4:00:00:00:00:00:04
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Corporation Third Party Marketplace Root
Validity
Not Before: Jun 27 21:22:45 2011 GMT
Not After : Jun 27 21:32:45 2026 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation,
CN=Microsoft Corporation UEFI CA 2011
<center>
Figure 11 - Correct diagram
</center>
## Task 3 - GRUB
:::info
9. Using your new knowledge about Authenticode binaries, extract the signing certificates from the GRUB boot loader, and show the subject and issuer.
:::
<center>
Figure 6 - Subject and issuer
Figure 7 - binaries
</center>
:::info
10. Why is storing the certificate X in the shim binary secure?
:::
If we are talking about a built-in canonical key, then this key checks GRUB and the Linux kernel. She is obliged to allow the larva following her to check the safe type of download. Without it, Canonical would have to sign every new release of GRUB and the Linux kernel with Microsoft, which is not practical. This is safe because the signature indicates that the file has not been modified after it has been signed. If we save the certificate X in the shell binary, we can be sure that it will not be changed.
:::info
11. What do you think is the subject CommonName (CN) of this X certificate?
:::
Canonical Ltd. Master Certificate Authority, because this certificate is most likely part of the chain of trust.
## Task 4 - The Kernel
## References:
1. [UEFI:SecureBoot](https://wiki.ubuntu.com/UEFI/SecureBoot)
2. [Official UEFI specification](https://uefi.org/specifications)
3. [Certificate authority (CA)](https://en.wikipedia.org/wiki/Certificate_authority)
4. [Man openssl](https://www.openssl.org/docs/man1.0.2/man1/x509.html)
5. [UEFI Documentation](https://uefi.org/sites/default/files/resources/UEFI%202_5.pdf)
6. [About Secure boot](http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html)
**Gold Collection forums:**
1. [Bog BOS: hardware: EFI, UEFI и PI](http://www.bog.pp.ru/hard/UEFI.html#efivar)
2. [git-MAN binwalk](https://github.com/ReFirmLabs/binwalk/wiki/Usage)
Sign in with Wallet
Connect another wallet