To be clear, this method isn't entirely new either. Similar methods were revealed as part of the Hacking Team tool dump a couple of years ago (http://www.intelsecurity.com/advanced-threat-research/ht_uefi_rootkit.html_7142015.html). However it is not as common as some of the other persistence menthods (Such as Run Keys or Scheduled Tasks).
The key to this method is the fact that, on boot, your Operating system needs to be able to read certain types of information from the Hardware. This requires the use of the firmware level. The particular firmware spec this targets is called the Unified Extensible Firmware Interface (UEFI). It is a specification that defines a software interface between an operating system and platform firmware. The documents describe it as such:
"NVRAM is non-volatile RAM that is used in EFI to store variables that need to persist between boots. Many of these NVRAM variables are architecturally defined, and setting invalid options to NVRAM could cause a machine to not be able to boot." (https://wikileaks.org/ciav7p1/cms/page_26968084.html)I bolded the section on invalid options because I think it is important to note before going further....if you brick a device while trying to do any of these tests, I am not responsible. Only go through this if you already know what you are doing (or you are comfortable losing the system you are messing with.) With that in mind I highly recommend you go read the details on the spec at http://uefi.org/uefi .
The Vault 7 documentation focuses on the potential use of the NVRAM as covert storage on Windows systems. So, like the articles, I will focus on the Windows.
Prerequisites
As I mentioned this is a method in the Post Exploitation phase, so we assume that the machine has already been compromised and that some basic form of persistent C2 has already been established (remember 2 is 1, 1 is none). This is just good practice, though. The only formal prerequisite is that you be operating in the context of a SYSTEM account with the SE_SYSTEM_ENVIRONMENT_NAME privilege. You can find out more about this privilege (and how to see if you have it) here https://msdn.microsoft.com/en-us/library/windows/desktop/bb530716(v=vs.85).aspxSetting Contents
The Windows API makes it easy to set this type of storage through one of two calls. The one of most use is SetFirmwareEnvironmentVariableEx, the structure of which is:More information can be found here https://msdn.microsoft.com/en-us/library/windows/desktop/jj204594(v=vs.85).aspx but a couple points to note are the lpName and lpGuid must not be NULL pointers, even though some systems may not actually support the GUID lookup. According to the docuemntation The GUID must be a string in the format "{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}" e.g. 8BE4DF61-93CA-11D2-AA0D-00E098032B8C which is defined as the GUID for the BootOrder variable. As mentioned previously, several of these are set aside by the specification, and then more yet are reserved for vendor-specific uses. As noted in the documents:BOOL WINBASEAPI SetFirmwareEnvironmentVariableEx( _In_ LPCTSTR lpName, _In_ LPCTSTR lpGuid, _In_ PVOID pValue, _In_ DWORD nSize, _In_ DWORD dwAttributes );
"NVRAM variables are a combination of a GUID of the variable owner, a name, and a value....These variables present interesting opportunities for our tools since they will survive a OS reinstall and are invisible to a forensic image of the hard drive. What's also interesting is that there is no way to enumerate NVRAM variables from the OS...you have to know the exact GUID and name of the variable to even determine that it exists. The variables are part of the BIOS image mapped into kernel memory, so it is possible to enumerate them from the kernel if a PSP knew where to look."The flow of such a persistence method would look something like this:
- Install Rootkit
- Rootkit patches UEFI driver for some device (e.g. the HDD) for details on UEFI drivers check http://www.intel.com/content/dam/www/public/us/en/documents/guides/uefi-driver-hardware-devices-guide.pdf
- Rootkit writes reinfection vector to NVRAM variables
- Operator gets suspicious and wipes the OS and installs a fresh copy.
- Upon booting the HDD UEFI firmware driver (patched) reads the Rootkit reinfection vector from NVRAM
- New System, same pwnage
Other OS families
Just because I focused on Windows doesn't mean Linux or OSX Users are in the clear. They are each discussed in turn in the Vault 7 Documentation of UEFI basics as well https://wikileaks.org/ciav7p1/cms/page_26968084.htmlEach presents it's own uniques pros and cons to the mix as well.
Mitigation
Setting aside the obvious blocking of initial exploitation vectors for a moment, I want to look at the detection and mitigation of this type of implant. First, as noted in the previous quote, there is no way to enumerate these variables from User land. The notes do say:"The variables are part of the BIOS image mapped into kernel memory, so it is possible to enumerate them from the kernel if a PSP knew where to look."The "place to look" is called the GUID Partition Table (GPT). As usual if you want more info on this, go to the docs https://support.microsoft.com/en-us/help/302873/frequently-asked-questions-about-the-guid-partitioning-table-disk-architecture. So, it may very well be possible to script the process of discovering suspicious NVRAM content. Regardless it would be impossible to completely reconstruct this from a forensic image of the machine (assuming the original machine were otherwise unobtainable).
Probably of more use is when you can physically access the potentially infected machine:
"If an adversary had physical access to the computer, then reading the NVRAM variables would be much easier. They could turn off secure boot in the UEFI menu and boot to a UEFI shell, which has a command to list all NVRAM variables."The command mentioned is the UEFI shell command dmpstore. Here is the usage specification from the UEFI Shell 2.0 documentation:
No comments:
Post a Comment