Return to Video

35C3 - First Sednit UEFI Rootkit Unveiled

  • 0:00 - 0:18
    35C3 preroll music
  • 0:18 - 0:23
    Herald angel: OK so our next talk is given
    by Frederic Vachon, so please give him a
  • 0:23 - 0:33
    warm round of applause.
    Applause
  • 0:33 - 0:39
    Vachon: Okay so hello everyone. Thank you
    for having me today. I'm really happy to
  • 0:39 - 0:46
    be to be here. So today I'm going to talk
    about a research that a colleague of mine,
  • 0:46 - 0:51
    Jean-Ian Boutin and I did earlier this
    year and which led us to the discovery of
  • 0:51 - 0:58
    a UEFI rootkit. So very quickly. My name
    is Frederic Vachon, I'm a malware
  • 0:58 - 1:05
    researcher at ESET and I've been working
    there for the last two years and for the
  • 1:05 - 1:12
    last year or so I've been really focusing
    on boot level threats and UEFI firmware
  • 1:12 - 1:17
    reverse engineering. So let's look at the
    agenda for this talk. So the first thing I
  • 1:17 - 1:23
    want to talk about is what is Sednit very
    quickly. Then I'll talk about LoJack,
  • 1:23 - 1:28
    which is an anti-theft software and past
    research related to this software and the
  • 1:28 - 1:33
    reason for that is that the UEFI rootkit
    that I'll talk about really mimics the
  • 1:33 - 1:39
    architecture of this legitimate software.
    Then we'll move on and I'll talk a little
  • 1:39 - 1:44
    bit about compromised LoJack agents that
    were found in the wild, and finally I'll
  • 1:44 - 1:50
    jump into the UEFI rootkit, well, where
    I'll talk about the tools around the
  • 1:50 - 1:57
    rootkit and the UEFI rootkit itself. So,
    Sednit. Sednit is an espionage group
  • 1:57 - 2:05
    active since the early 2000s and it is
    also known as Fancy Bear, APT28 and
  • 2:05 - 2:12
    STRONTIUM, so maybe you know this group by
    one of these alternative names. And Sednit
  • 2:12 - 2:19
    is the name basically that we use at ESET.
    So this group was very visible in the past
  • 2:19 - 2:25
    few years as being allegedly behind some
    pretty mysterious hacks like the hack
  • 2:25 - 2:30
    against the Democratic National Committee,
    the DNC, where some emails were leaked
  • 2:30 - 2:36
    online. The hack against the World Anti-
    Doping Agency as well as the hack against
  • 2:36 - 2:42
    the French broadcasting network TV5 Monde.
    But at ESET when we're talking about
  • 2:42 - 2:46
    Sednit, we're really talking about the
    tools and the different campaigns that
  • 2:46 - 2:52
    were led using these tools, and we're not
    talking about the people who are operating
  • 2:52 - 2:57
    this malware because we don't have the
    information necessary to draw such
  • 2:57 - 3:05
    conclusions. However, in July 2018 the
    U.S. Department of Justice named the group
  • 3:05 - 3:11
    as being responsible for the Democratic
    National Committee hack in this specific
  • 3:11 - 3:18
    indictment. And what's interesting is that
    the tools that we analyzed were... are
  • 3:18 - 3:27
    named in this specific indictment and they
    also mention who's the authors of these
  • 3:27 - 3:37
    malware. And also early, not earlier, but
    closer from from now, in October 2018, the
  • 3:37 - 3:41
    Department of Justice issued another
    indictment naming pretty much the same
  • 3:41 - 3:49
    people are related to the World Anti-
    Doping Agency hack. And the way that
  • 3:49 - 3:54
    Sednit will usually infect their targets
    is by sending phishing emails, so
  • 3:54 - 3:59
    sometimes they will contain malicious
    links and some of the time malicious
  • 3:59 - 4:06
    attachments. OK. So now let's talk a
    little bit about LoJack. So Lojack is an
  • 4:06 - 4:10
    anti-theft software as I mentioned, and it
    was previously known as Computrace. So
  • 4:10 - 4:16
    maybe you know the solution by this name
    instead. And it is made by Absolute
  • 4:16 - 4:26
    Software. So, yeah, and this solution is
    built in many laptops. But an anti-theft
  • 4:26 - 4:31
    software needs to be as persistent as
    possible if you want it to be reliable. It
  • 4:31 - 4:36
    needs to be... to survive an operating
    system re-install or a hard disk
  • 4:36 - 4:41
    replacement. So to achieve this what
    Absolute Software did is that they added a
  • 4:41 - 4:49
    module in the UEFI BIOS itself. Yeah and
    the solution needs to be activated in the
  • 4:49 - 4:54
    BIOS setup. So with a persistence
    mechanism like that coming from the
  • 4:54 - 4:58
    firmware, it's really attracted the
    attention of security researchers, who
  • 4:58 - 5:05
    looked into this to find vulnerabilities
    basically. And at BlackHat in 2009 there
  • 5:05 - 5:12
    was a talk there where the architecture of
    the solution was described and several
  • 5:12 - 5:18
    design vulnerabilities in the agent were
    also described there. So let's look at the
  • 5:18 - 5:26
    architecture of LoJack back then. So the
    first thing that we have here is a module
  • 5:26 - 5:32
    in the UEFI BIOS, and this module will
    write a file to the Windows partition. So
  • 5:32 - 5:37
    this file is called autochk.exe, which
    replaces the legitimate autochk.exe, whose
  • 5:37 - 5:44
    job is to perform filesystem integrity
    check during early Windows boot. So by
  • 5:44 - 5:51
    replacing this agent during early Windows
    boot it will be executed. And from there
  • 5:51 - 5:58
    it will drop rpcnetp.exe, which is the
    small agent, and will install a service
  • 5:58 - 6:03
    and when Windows will run it will run this
    service, and rpcnetp will be launched at
  • 6:03 - 6:09
    this point. And it will inject itself into
    svchost , and then from there it will
  • 6:09 - 6:14
    inject itself into Internet Explorer which
    is pretty interesting because it's very
  • 6:14 - 6:18
    shady and that's something that we see
    pretty much all the time in malware but
  • 6:18 - 6:24
    not often in legitimate software. And from
    Internet Explorer it will then communicate
  • 6:24 - 6:32
    with the command and control server and it
    will download the full recovery agent. So
  • 6:32 - 6:38
    now let's look at some of the issues that
    the researchers found with this... in this
  • 6:38 - 6:45
    solution. So one of the vulnerabilities
    they found is very interesting for us and
  • 6:45 - 6:49
    in fact that's really the only one that
    matters for this talk. And this is a
  • 6:49 - 6:56
    configuration file vulnerability. So the
    configuration is embedded into rpcnetp.exe
  • 6:56 - 7:01
    and it is encrypted but it is encrypted
    with a very weak algorithm. So it is in
  • 7:01 - 7:08
    single byte XOR key, and it is not
    authenticated whatsoever. And what's in
  • 7:08 - 7:15
    this configuration file? Well, that's
    where you can find the server, the command
  • 7:15 - 7:21
    and control server. So an attacker can
    just change this configuration to point to
  • 7:21 - 7:28
    its own attacker-controlled server. So we
    knew that this vulnerability existed for a
  • 7:28 - 7:35
    while, it was back in 2009, but we had no
    evidence of it being used in the wild.
  • 7:35 - 7:41
    Until earlier this year, when Arbor
    Networks published a blog post where they
  • 7:41 - 7:47
    described some modified small agent with
    modified configuration where the domains
  • 7:47 - 7:55
    that were embedded in this configuration
    were linked to old Sednit domains. So
  • 7:55 - 8:01
    let's go back to LoJack architecture and
    look at where this attack took place. So
  • 8:01 - 8:16
    it took place at this level here. So from
    there we did some detection for this
  • 8:16 - 8:24
    malware and it was... and we hunted to
    gather as much samples as as we could. And
  • 8:24 - 8:31
    it was fairly simple because they always
    modified the same exact version of the
  • 8:31 - 8:37
    agent and they modified, so that's what we
    can see here, so they modified the command
  • 8:37 - 8:43
    and control server. And here we see the
    encrypted version of course. So by looking
  • 8:43 - 8:49
    at this we will look at ESET's telemetry
    and found out that there was a few
  • 8:49 - 8:53
    organizations that were hit mostly in the
    Balkans, in Central Europe as well as in
  • 8:53 - 8:59
    Eastern Europe. These were military and
    diplomatic organizations. And what's
  • 8:59 - 9:07
    interesting is that we also found other
    Sednit tools in the same organization. So
  • 9:07 - 9:12
    at this point we wondered how this malware
    got there, but since there was other
  • 9:12 - 9:17
    backdoors of Sednit in the organization we
    thought it might be the infection vector,
  • 9:17 - 9:22
    but by digging a little bit deeper we
    found another interesting component. And
  • 9:22 - 9:29
    if we go back to the LoJack architecture,
    the component that we found is at this
  • 9:29 - 9:35
    step here. So at this step in the LoJack
    architecture it's autochk.exe that lives
  • 9:35 - 9:41
    there. But what we found is another file
    called autoche.exe instead of autochk. And
  • 9:41 - 9:47
    it does pretty much the same thing. So it
    also installs a service and it also drops
  • 9:47 - 9:54
    rpcnetp.exe. But it is the rpcnetp version
    that has a modified server in it. So
  • 9:54 - 10:00
    Sednit domain basically. And we continue
    to look at what we can find in this
  • 10:00 - 10:06
    organization and we found another tool
    which is called info_efi.exe, and that
  • 10:06 - 10:10
    allows to drop... to dump a lot of
    information about very low level settings
  • 10:10 - 10:18
    of the machine. And this tool uses Read
    Write Everything's driver. And
  • 10:18 - 10:23
    Read Write Everything is a software that allows you
    to manipulate very low level setting of
  • 10:23 - 10:28
    your machine. So using this tool you can
    read and write to PCI configuration
  • 10:28 - 10:33
    register, to memory-mapped IOs, to IO port
    space and you can also access physical
  • 10:33 - 10:38
    memory and this tool uses a kernel driver
    of course - if you want to do those things
  • 10:38 - 10:43
    you need a kernel driver. And this kernel
    driver is properly signed so that you can
  • 10:43 - 10:50
    push it on even a recent version of
    Windows. And so yeah, that's the driver
  • 10:50 - 10:57
    that was used by info_efi here. And by
    Googling a little bit around what we found
  • 10:57 - 11:02
    out is that this specific driver was used
    in the past by security researchers to
  • 11:02 - 11:10
    exploit vulnerabilities at the firmware
    level. So, yeah, the last thing that was
  • 11:10 - 11:17
    missing here to mimic the whole LoJack
    solution was a UEFI BIOS module. So at
  • 11:17 - 11:25
    this point we wondered, did they get
    there. So, because of the tool dumping
  • 11:25 - 11:28
    information about the BIOS that I just
    spoke about, we were pretty confident that
  • 11:28 - 11:34
    something more was happening there. And by
    digging a little bit deeper, we found
  • 11:34 - 11:40
    other tools that strengthen our
    suspicions. So the first tool is called
  • 11:40 - 11:47
    ReWriter_read. And it is a tool used to
    dump the content of the SPI flash memory,
  • 11:47 - 11:54
    and it also uses Read Write Everything's driver and
    it uses these specific IO control codes.
  • 11:54 - 12:00
    So it allows it to read and write to
    memory-mapped IO space as well as read and
  • 12:00 - 12:06
    write to PCI configuration registers.
    What's interesting for us as reverse
  • 12:06 - 12:10
    engineer is that this tool contains a lot
    of debug strings which really made our job
  • 12:10 - 12:17
    easier. And it consists of the following
    operations. So the first thing it will do
  • 12:17 - 12:22
    is that it will log information on the
    BIOS_CNTL register and we'll talk a lot of
  • 12:22 - 12:28
    detail about this register just a little bit later
    in this talk. Then it locates the BIOS
  • 12:28 - 12:35
    region base address. And finally it reads
    the UEFI firmware content and dump it to a
  • 12:35 - 12:42
    file. So another tool that we found is
    really complementary to the tool to
  • 12:42 - 12:47
    ReWriter_read and it is called
    ReWriter_binary. So it also contains a lot
  • 12:47 - 12:54
    of debug strings. It also uses
    RWEverything's driver. And now the UEFI
  • 12:54 - 12:59
    firmware is dumped into memory, the next
    step is to add the rootkit to the firmware
  • 12:59 - 13:02
    and to write it back to the SPI flash
    memory and that's exactly what this tool
  • 13:02 - 13:10
    does. Okay. So now let's talk about the
    patching of the UEFI firmware. But before
  • 13:10 - 13:13
    we dig into the subjects there are a
    couple things that I wanted to introduce
  • 13:13 - 13:17
    here just to make sure that we're on the
    same page. So the first thing I want to
  • 13:17 - 13:23
    talk about is UEFI and UEFI stands for
    Unified Extensible Firmware Interface and
  • 13:23 - 13:27
    it is a standardized specification that
    defines the interface that exists between
  • 13:27 - 13:32
    the operating system and the firmware. And
    it's kind of a replacement for the legacy
  • 13:32 - 13:39
    BIOS. So, a UEFI compliant firmware will
    provide a set of services to UEFI
  • 13:39 - 13:44
    applications and here read the operating
    system loader. There are other UEFI
  • 13:44 - 13:51
    applications, but usually it's the
    operating system loader that runs. So the
  • 13:51 - 13:55
    first set of services is called the boot
    services and these are services that are
  • 13:55 - 14:00
    available during the firmware lifetime but
    once the operating system is loaded, these
  • 14:00 - 14:04
    services are not available anymore and
    there are the runtime services that are
  • 14:04 - 14:11
    also available during firmware lifetime.
    But once the operating system is loaded
  • 14:11 - 14:15
    they are still available, so that a kernel
    driver for instance can make call in these
  • 14:15 - 14:21
    services. An example of these services
    allows the operating system to read and
  • 14:21 - 14:26
    write to UEFI variables. And what's
    interesting with UEFI is that there is no
  • 14:26 - 14:31
    more master boot record and volume boot
    record involved in the boot process
  • 14:31 - 14:38
    meaning that there is no easy way to
    hijack the early boot control flow. So the
  • 14:38 - 14:43
    second thing I want to introduce here are
    the driver execution environment drivers -
  • 14:43 - 14:48
    so the DXE drivers. So DXE drivers are
    PE/COFF images meaning that they are
  • 14:48 - 14:54
    basically Windows executables, and they
    are kind of the core of UEFI firmware so
  • 14:54 - 14:58
    that they can do many things, some of them
    will be used to abstract the hardware.
  • 14:58 - 15:01
    Some of them will be used to produce the
    UEFI standard interface, so the boot
  • 15:01 - 15:06
    services and the runtime services, and
    they can also be used by firmware vendors
  • 15:06 - 15:12
    or OEMs to extend the firmware by
    registering new services - the so-called
  • 15:12 - 15:17
    protocols in the UEFI specification. And,
    the DXE drivers are loaded during the DXE
  • 15:17 - 15:22
    phase of the platform initialization and
    they are loaded by the DXE dispatcher that
  • 15:22 - 15:29
    will also be referred to as the DXE Core.
    The last thing that I'm going to do: I
  • 15:29 - 15:34
    want to introduce for now is the UEFI
    firmware layout - so the UEFI firmware
  • 15:34 - 15:40
    is located in the BIOS region of the SPI
    flash memory. And this region will contain
  • 15:40 - 15:46
    multiple volume. But let's look at it with
    a little bit more detail in this tool here
  • 15:46 - 15:51
    which is UEFI tool, that is an open source
    software that allows you to manipulate
  • 15:51 - 15:57
    UEFI firmware images. So here I loaded the
    typical content of SPI flash memory dump
  • 15:57 - 16:02
    in this tool and let's look at what we
    have. So, the first thing that we see here
  • 16:02 - 16:06
    is the descriptor region, so it contains...
    this region contains metadata about how
  • 16:06 - 16:11
    the remaining data in the SPI flash memory
    is laid out. The second region that we
  • 16:11 - 16:17
    find here is the ME region which contains
    the Intel Management Engine firmware. And
  • 16:17 - 16:20
    finally we have the BIOS region which is
    really the main interest... the main thing
  • 16:20 - 16:28
    that we want to look at today. So the BIOS
    region contains multiple volumes. So let's
  • 16:28 - 16:33
    look at one volume in a little bit more
    detail. So here we have a volume of type
  • 16:33 - 16:38
    firmware filesystem version 2 and this
    volume contains multiple files and these
  • 16:38 - 16:42
    files are identified by GUIDs. So that's
    what we can see under the name column
  • 16:42 - 16:50
    here. And a file doesn't contain directly
    the UEFI executable, but it is composed of
  • 16:50 - 16:55
    multiple sections and one of these section
    is the actual UEFI executable, but there
  • 16:55 - 16:59
    are other section and in this case we see
    a DXE dependency section that allows to
  • 16:59 - 17:06
    define dependencies for this specific UEFI
    image and we also see a version section
  • 17:06 - 17:10
    and a user interface section which allows
    to give us a human readable name for this
  • 17:10 - 17:17
    file instead of the GUID which is very
    pretty difficult to remember for humans.
  • 17:19 - 17:24
    OK, so now that we have all this in mind
    let's go back to ReWriter_binary. So what
  • 17:24 - 17:29
    ReWriter_binary will do is that it will
    parse all of the firmware volumes that it
  • 17:29 - 17:37
    can find looking for 4 specific files. So
    it looks for Ip4Dxe, NtfsDxe, SmiFlash,
  • 17:37 - 17:43
    and the DXE Core. So why does it look for
    Ip4Dxe and the DXE Core? Well these files
  • 17:43 - 17:48
    are looked for to find the firmware volume
    where to install the UEFI rootkit. So
  • 17:48 - 17:55
    usually in UEFI firmwares all of the DXE
    drivers all in the same volume, so when
  • 17:55 - 17:59
    the tool will parse... will find in fact
    Ip4Dxe, it will know it is currently
  • 17:59 - 18:04
    parsing the volume with all of the DXE
    drivers in it and it will keep it as a
  • 18:04 - 18:08
    candidate for the UEFI rootkit
    installation. And it looks for the DXE
  • 18:08 - 18:13
    Core basically for the same reason, but
    sometimes the DXE Core is in a different
  • 18:13 - 18:17
    volume, so when it will find it, it will
    keep the volume as another candidate for
  • 18:17 - 18:22
    the UEFI rootkit installation and the
    chosen volume will be the one with enough
  • 18:22 - 18:31
    free space available in it. Now, NtfsDxe.
    So NtfsDxe is the American Megatron Inc.
  • 18:31 - 18:38
    NTFS driver and if the tool finds it, it
    will remove it, and the reason for that is
  • 18:38 - 18:44
    that the UEFI rootkit embeds its own NTFS
    driver, so to avoid any conflict with
  • 18:44 - 18:52
    another NTFS driver it just removes it.
    And now SmiFlash, so, SmiFlash is looked
  • 18:52 - 18:57
    for... and, you know, the tool will... if
    the tool finds it, it will keep some
  • 18:57 - 19:01
    metadata about it in the structure, but in
    the version of the tool that we analyzed
  • 19:01 - 19:07
    it's not used anywhere. But interestingly,
    SmiFlash is a known vulnerable DXE driver.
  • 19:08 - 19:11
    So what we believe is that Sednit might
    have been fiddling in another version of
  • 19:11 - 19:16
    the tool with some exploit for this driver
    in order to be able to bypass write
  • 19:16 - 19:22
    protection mechanisms to the BIOS region
    of the SPI flash memory. So now that it
  • 19:22 - 19:29
    has found the volume where to install the
    rootkit, it will add the rootkit, right.
  • 19:29 - 19:34
    So the first thing it does, it will create
    a firmware file system file header, then
  • 19:34 - 19:39
    it will append the rootkit file, which is
    a compressed section that contains two
  • 19:39 - 19:47
    other sections, one of one of these is the
    actual UEFI rootkit image and the other
  • 19:47 - 19:53
    one is a user interface section defining
    the name for this rootkit which is SecDXE,
  • 19:53 - 20:00
    as in security DXE. And then it will take
    this blob of data and write it at the end
  • 20:00 - 20:02
    of the firmware volume that was chosen.
  • 20:11 - 20:14
    So now that the UEFI rootkit is inside the
  • 20:14 - 20:20
    firmware into memory, the next step is to
    write it back to the SPI flash memory. And
  • 20:20 - 20:24
    once again there's a couple of things that
    I want to introduce here. So I want to
  • 20:24 - 20:29
    talk about BIOS write protection
    mechanisms. So the chipset exposes write
  • 20:29 - 20:34
    protection mechanisms that need to be
    properly configured by the firmware. So
  • 20:34 - 20:39
    there are no such thing as, you know, BIOS
    write particular mechanism enabled by
  • 20:39 - 20:43
    default. It's really the job of the
    firmware to do that. And today will only
  • 20:43 - 20:48
    cover relevant protections to our
    research. So only the protection mechanism
  • 20:48 - 20:55
    that are looked for by
    REWriter_binary. And yeah the protection
  • 20:55 - 20:59
    we'll talk about are exposed via the BIOS
    control register that we've seen a little
  • 20:59 - 21:04
    bit earlier in this talk. So, if you're a
    kernel driver and you want to write to be
  • 21:04 - 21:09
    BIOS region of the SPI flash memory, what
    you need to do first is you need to set
  • 21:09 - 21:14
    the BIOS Write Enable field of the BIOS
    control register to 1 and then you're able
  • 21:14 - 21:21
    to write to the SPI flash memory. But of
    course you don't want any kernel driver to
  • 21:21 - 21:26
    be able to modify your UEFI firmware and
    potentially brick your machine. So there's
  • 21:26 - 21:30
    a protection mechanism there which is
    another field in the BIOS control register
  • 21:30 - 21:36
    and this field is called BIOS lock enable
    and it allows to lock BIOS Writer Enable to
  • 21:36 - 21:45
    0. And this field is readable in WLO. WLO
    means write lock once. And what it means
  • 21:45 - 21:49
    is that once the firmware has set this bit
    there's no other way to set it back to 0
  • 21:49 - 21:50
    than performing a full platform reset.
  • 21:53 - 21:56
    But there's a problem here, and it lies in the
  • 21:56 - 22:03
    fact that BIOS lock enable implementation
    is vulnerable. So how it works is that
  • 22:03 - 22:11
    when BIOS write enable is set to 1, it's
    value will actually change in the BIOS
  • 22:11 - 22:16
    control register for a small amount of
    time. And then the platform will issue a
  • 22:16 - 22:22
    system management interrupt and the SMI
    handler will set BIOS write enable back to
  • 22:22 - 22:28
    0. But, yeah, the firmware must implement
    this SMI, otherwise this mechanism is
  • 22:28 - 22:35
    totally useless. But maybe you've guessed
    it. But what happens if we write to the
  • 22:35 - 22:41
    SPI flash memory before the SMI handler
    sets BIOS write enable back to 0? So there
  • 22:41 - 22:46
    is a race condition vulnerability here.
    And there is a paper about it which is
  • 22:46 - 22:50
    called "speed racer". And to exploit this
    what you need to do is, you need one
  • 22:50 - 22:55
    thread that continuously sets BIOS write
    enable to 1, while another thread tries to
  • 22:55 - 23:00
    write the data to the SPI flash memory.
    And according to this paper it works on
  • 23:00 - 23:04
    multicore processors as well as on single
    core processors with hyper-threading
  • 23:04 - 23:10
    enabled. So Intel came up with a fix for
    this issue and was introduced in the
  • 23:10 - 23:15
    platform controller hub family of Intel
    chipsets around 2008. And what they did
  • 23:15 - 23:20
    is, that they added a field in the BIOS
    control register. And this field is called
  • 23:20 - 23:25
    SMM BIOS write protect disable. And the
    name is a little bit misleading, but if
  • 23:25 - 23:30
    you remove disable, that's actually what
    it does. And if this mechanism is
  • 23:30 - 23:35
    activated, there will be no other way to
    write to the SPI, to the BIOS region of
  • 23:35 - 23:41
    the SPI flash memory, than if you don't
    have all of the cores of your processor
  • 23:41 - 23:48
    running into SMM, meaning that the job of
    writing to the SPI flash memory is now only
  • 23:48 - 23:54
    available to system management mode. And
    once again the firmware must set this bit.
  • 23:54 - 24:03
    Otherwise this mechanism is not activated,
    right. Okay so let's go back to
  • 24:03 - 24:07
    ReWriter_Binary. So of course if I talk
    about all of these mechanisms it's because
  • 24:07 - 24:11
    ReWriter_Binary checks for them. So it
    will check if the platform is properly
  • 24:11 - 24:17
    configured and it implements the exploit
    for the race condition that I just spoke
  • 24:17 - 24:23
    about. So let's look at the writing
    process decision tree. So the first thing
  • 24:23 - 24:29
    that it will look for is if BIOS write
    enable is set, and if BIOS write enable is
  • 24:29 - 24:35
    set there, then there's nothing stopping
    it from writing the UEFI image. But if it
  • 24:35 - 24:40
    is not set, then it will check "Oh, is
    BIOS lock enable activated?". And this, if
  • 24:40 - 24:46
    this mechanism is not activated then it
    will just flip BIOS write enable to 1, and
  • 24:46 - 24:50
    then it will write the UEFI image. But if
    it is activated, the last thing it will
  • 24:50 - 24:57
    check for is "Is SMM BIOS write protect
    set?". And if it is not set, then it will
  • 24:57 - 25:03
    exploit the race condition that we spoke
    about. And if it is set, then the tool
  • 25:03 - 25:11
    will just fail. So the tool only works if
    the platform is misconfigured. And we
  • 25:11 - 25:17
    spoke about SmiFlash, the vulnerable DXE
    driver. So yeah, what we think is that by
  • 25:17 - 25:21
    being able to exploit this vulnerability,
    they would have been able to have a tool
  • 25:21 - 25:28
    that works even when the platform is
    properly configured. So it's a very good
  • 25:28 - 25:36
    example of; I mean if firmware vendors
    would have done their job correctly here,
  • 25:36 - 25:41
    this tool would have failed at flashing
    the UEFI firmware, so that's a great
  • 25:41 - 25:47
    example of how, you know, firmware
    security is. So here let's just take a
  • 25:47 - 25:52
    step back and look at what we have. So
    what we have is a software implementation
  • 25:52 - 25:57
    to flash the firmware remotely post
    exploitation, meaning that as an attacker
  • 25:57 - 26:03
    I can, you know, infect my target the way
    I usually do - let's say by sending a
  • 26:03 - 26:07
    phishing email. And once I have a foothold
    in the machine, I can use this tool to
  • 26:07 - 26:13
    deploy the UEFI rootkit. And one we knew
    about in the past was Hacking Team's UEFI
  • 26:13 - 26:19
    rootkit and it needed physical access to
    be deployed. So it's so much more
  • 26:19 - 26:25
    convenient to be able to do it remotely.
    And let's note here that there is no proof
  • 26:25 - 26:30
    of Hacking Team's rootkit being used in an
    actual cyber attack. It has never been
  • 26:30 - 26:37
    found on a victim's machine or at least if
    it had, it hasn't been publicly disclosed.
  • 26:37 - 26:41
    So what we did at this point is that we
    extracted the UEFI rootkit from the tool
  • 26:41 - 26:47
    and we looked at ESET's UEFI scanner
    telemetry to see if we can find something.
  • 26:47 - 26:52
    Turns out that we found the UEFI rootkit
    in the SPI flash memory of a victim's
  • 26:52 - 26:58
    machine, making it the first publicly
    known UEFI rootkit to be used in an actual
  • 26:58 - 27:01
    cyber attack. Okay.
  • 27:01 - 27:15
    So now let's look at the UEFI
    rootkit itself. So the UEFI
  • 27:15 - 27:19
    rootkit is a DXE driver. So it is loaded
    by the DXE dispatcher every time that the
  • 27:19 - 27:26
    machine will boot. Its file name is SecDxe
    as we've seen earlier and here's the file
  • 27:26 - 27:34
    GUID for future reference. So let's look
    at the UEFI rootkit workflow. So UEFI
  • 27:34 - 27:37
    firmware we'll go through multiple phases
    when it boots. The first phase is the
  • 27:37 - 27:41
    security phase, the second one is the pre
    EFI initialization phase, and then there
  • 27:41 - 27:45
    is the driver execution environment phase
    and that's where it begins to be
  • 27:45 - 27:51
    interesting for this rootkit. So that's
    where the DXE dispatcher lives. So that's
  • 27:51 - 27:56
    when all of the DXE drivers will be
    loaded. So at some point the UEFI rootkit
  • 27:56 - 28:02
    will be loaded. And what will happen is
    that the rootkit will create an event
  • 28:02 - 28:08
    attached to EFI GROUP_READY_TO_BOOT. And
    it will bind a notify function to this
  • 28:08 - 28:14
    event. So in the next phase, when the boot
    manager will run, at some point it will
  • 28:14 - 28:22
    signal this event and the notify function
    will be called. So, the notify function
  • 28:22 - 28:29
    does 3 things. The first thing is that it
    will install an NTFS driver. Then it will
  • 28:29 - 28:35
    drop autoche.exe and rpcnetp.exe using
    this NTFS driver. And finally it will
  • 28:35 - 28:43
    patch a value in the Windows Registry. So,
    the NTFS driver is needed to get file
  • 28:43 - 28:50
    based access to Windows partition and
    Sednit's operator did not write their own
  • 28:50 - 28:56
    NTFS driver. What did it is that they use
    Hacking Team's NTFS driver from Hacking
  • 28:56 - 29:04
    Team's leak. And, yeah, so here's the code
    responsible for dropping the files. So as
  • 29:04 - 29:08
    we can see here, it is dropping
    rpcnetp.exe and here it is dropping
  • 29:08 - 29:17
    autoche.exe. And the last step is to patch
    the Windows Registry. So how it does that
  • 29:17 - 29:23
    is that it will open the file backing the
    HKLM\SYSTEM Registry hive and it doesn't
  • 29:23 - 29:28
    have all the logic to parse Windows
    Registry structures, so it will only look
  • 29:28 - 29:32
    for a textual pattern and the textual
    pattern it will look for is "autocheck
  • 29:32 - 29:37
    autochk " and it will change it to
    "autocheck autoche
    " and it happens to be
  • 29:37 - 29:43
    modifying the BootExecute key. So, the
    BootExecute key is the key responsible for
  • 29:43 - 29:51
    launching autochk.exe during Windows early
    boot. So by modifying it to autoche
  • 29:51 - 29:57
    instead of autochk that's autoche.exe that
    will be executed instead of autochk. And,
  • 29:57 - 30:01
    so here if we go back to the UEFI rootkit
    workflow, when the operating system will
  • 30:01 - 30:06
    run, then it will execute autoche.exe.
    Then autoche.exe will drop the small
  • 30:06 - 30:13
    agent, the rpcnetp.exe, and so on. But
    what's interesting here is that it will
  • 30:13 - 30:19
    revert back the modification in the
    Windows Registry from autoche to autochk.
  • 30:19 - 30:24
    So that as a Windows user, for instance,
    if I look in the Windows Registry, I won't
  • 30:24 - 30:29
    find that anything, any modification
    occurred there. So that's a pretty
  • 30:29 - 30:32
    interesting sealth technique that is
    enabled by the fact that the malware is
  • 30:32 - 30:42
    coming from the firmware. Okay. So, the
    last thing that I want to talk about now
  • 30:42 - 30:51
    is prevention and remediation, so what can
    you do to protect yourself against this
  • 30:51 - 30:56
    kind of attack? And if ever you were...
    you find out that you had a UEFI rootkit in
  • 30:56 - 31:04
    your machine, what can you do? So,
    prevention. So the first thing and the
  • 31:04 - 31:11
    most important thing, which is also the
    most accessible thing, thankfully, is that
  • 31:11 - 31:16
    you should keep your UEFI firmware up to
    date to make sure that if, you know,
  • 31:16 - 31:24
    security researchers found some issues
    with your firmware and they disclosed it
  • 31:24 - 31:28
    and the firmware vendor fixed them, you
    want to make sure that you have the latest
  • 31:28 - 31:34
    patches available on your machine. Then
    the second thing is that you should really
  • 31:34 - 31:39
    enable Secure Boot. But let's note here
    that Secure Boot itself would not
  • 31:39 - 31:43
    effectively you against this specific
    attack. And the reason for that is that
  • 31:43 - 31:49
    Secure Boot takes the content of the SPI
    flash memory as its root of trust, meaning
  • 31:49 - 31:56
    that what's inside the SPI flash memory is
    not subject for validation. So what does
  • 31:56 - 32:00
    it validates then, right? Well, Secure
    Boot will check what's coming from outside
  • 32:00 - 32:04
    of the SPI flash memory meanings the PCI
    option ROMs and probably the most
  • 32:04 - 32:09
    important thing, the operating system
    loader. So it's really a mechanism that
  • 32:09 - 32:15
    checks that the operating system loader
    hasn't been tampered with. So what can we
  • 32:15 - 32:21
    do then, right? Well, what we need is a
    hardware root of trust. So we need to move
  • 32:21 - 32:26
    the root of trust from the SPI flash
    memory to some piece of hardware. So it
  • 32:26 - 32:31
    must be in a, you know, one time
    programmable chip that is programmed
  • 32:31 - 32:39
    during manufacturing time and that cannot
    be written to ever after. An example of
  • 32:39 - 32:45
    this exists - technology like Intel
    BootGuard implements this. And also Apple
  • 32:45 - 32:52
    T2 security chip has a hardware root of
    trust. And then you kind of need to hope
  • 32:52 - 32:57
    that your firmware configures the security
    mechanisms properly and there's not much
  • 32:57 - 33:02
    you can do about it if your firmware is
    up-to-date. But thankfully there are
  • 33:02 - 33:06
    firmware security assessment tool
    available out there and an example of that
  • 33:06 - 33:13
    is Intel CHIPSEC. So, with Intel CHIPSEC
    which is an open source software tool, so
  • 33:13 - 33:19
    you can just download this tool, put it in
    an USB key, boot from it and then this
  • 33:19 - 33:23
    tool will check for all of the security
    mechanism that we spoke about today, it
  • 33:23 - 33:29
    will check if they are properly configured
    and also it checks for a bunch more stuff.
  • 33:29 - 33:38
    And now also CHIPSEC checks if your
    firmware has this LoJax rootkit. So if you
  • 33:38 - 33:42
    want to know if your firmware properly
    configures these security mechanism that's
  • 33:42 - 33:52
    really the way to go. Now about
    remediation. So, this slide is kind of
  • 33:52 - 33:57
    short. And the reason for that is that if
    you find out that you have a UEFI rootkit
  • 33:57 - 34:02
    in your SPI flash, there's not pretty much
    you can do. You really need to re-flash
  • 34:02 - 34:07
    your UEFI firmware and that's definitely
    not something that is easy to do for
  • 34:07 - 34:13
    anybody. And well, if it's not an option
    for you, then you kind of need to get rid
  • 34:13 - 34:19
    of your motherboard or your laptop and get
    a new one basically. So that's how serious
  • 34:19 - 34:29
    this kind of attack is. Now, conclusion.
    So, our research shows that UEFI rootkits
  • 34:29 - 34:35
    are not only toys for researchers to play
    with, but they are real world threats used
  • 34:35 - 34:41
    in actual cyber attacks. So it might be
    something that you want to keep in mind
  • 34:41 - 34:48
    when you'll be defining your threat model.
    Also we won't stress this enough: firmware
  • 34:48 - 34:53
    must be built with security in mind from
    the bottom up, and things are getting
  • 34:53 - 34:57
    better because there are more and more
    security researchers looking into this,
  • 34:57 - 35:04
    but there's still work to do. And
    hopefully, our research help share
  • 35:04 - 35:11
    knowledge about how to prevent and
    mitigate UEFI-based threats. So that is
  • 35:11 - 35:17
    pretty much it for me today. So thank you
    for having me and if ever you're
  • 35:17 - 35:22
    interested to know more details about this
    research, the white paper is available at
  • 35:22 - 35:28
    welivesecurity.com and you can grab a copy
    there. So, thanks.
  • 35:28 - 35:38
    Applause
    Herald: Alright, you know the drill. We
  • 35:38 - 35:44
    have 5 minutes for Q&A. So please, quick
    and short questions. Number 1 please.
  • 35:46 - 35:56
    Question: (incomprehensible) attacking
    other operating systems (incomprehensible)
  • 35:56 - 36:01
    Answer: In this case, well, that's kind of
    the... pretty much the only one we're aware
  • 36:01 - 36:07
    of, apart from Hacking Team's UEFI
    rootkit, and this one only works on
  • 36:07 - 36:13
    Windows, so we have no; we don't know
    about any other that target's Linux or Mac
  • 36:13 - 36:14
    OS for instance.
  • 36:16 - 36:19
    Herald: Please refrain from walking in
    front of the cameras when you're leaving.
  • 36:19 - 36:23
    Thank you.
    Could we get microphone number
  • 36:23 - 36:28
    2 please.
    Q: Hello, thanks for the talk. On your
  • 36:28 - 36:36
    slides you mentioned a tool, open source,
    for checking out the layout. What was the
  • 36:36 - 36:42
    name of the tool?
    A: It's called UEFI tool. Laughter
  • 36:42 - 36:44
    Q: Nice.
    A: So you can find it on GitHub.
  • 36:45 - 36:47
    Q: Thanks.
    Herald: The internet please.
  • 36:47 - 36:54
    Q: Thank you. Does the rootkit also work
    when the UEFI is in BIOS legacy mode?
  • 36:56 - 37:06
    A: Uhm... That is a pretty good question.
    I think it should, but I am not sure about
  • 37:06 - 37:13
    it. That's a good question, I'd have to
    look into this, to have a... laughing an
  • 37:13 - 37:17
    answer I'm 100 percent sure about. Sorry
    for that.
  • 37:17 - 37:25
    Herald: Microphone number 3 please. It's
    you in the back, are you? No that's 4,
  • 37:25 - 37:30
    I'm sorry.
    Q: OK. So, does the UEFI dropper still
  • 37:30 - 37:33
    work with BitLocker enabled?
  • 37:35 - 37:38
    A: I know. Oh yeah. Yeah. We test that.
  • 37:38 - 37:47
    No, it doesn't work if BitLocker is
    enabled, so it doesn't wait for the... for
  • 37:47 - 37:52
    BitLocker to have decrypted all of the
    data. So no, it doesn't work if
  • 37:52 - 37:54
    BitLocker is enabled.
  • 37:56 - 37:57
    Herald: Number 1 please.
  • 38:00 - 38:08
    Q: Would it be possible to work within
    full disk encryption. (incomprehensible)
  • 38:08 - 38:12
    the file system was decrypted and then
    installed the dropper.
  • 38:12 - 38:16
    A: I'm not sure I heard all of the
    question, but if it works if there's full
  • 38:16 - 38:23
    disk encryption? Is it the question right?
    Q: Would it be possible to make it work
  • 38:23 - 38:29
    with full disk encryption?
    A: I think it should be because the LoJack
  • 38:29 - 38:33
    software is a legitimate one, the anti-
    theft solution. They are able to make it
  • 38:33 - 38:39
    work even if BitLocker is enabled or full
    disk encryption. So yeah, it should be
  • 38:39 - 38:41
    possible to do so.
  • 38:42 - 38:44
    Herald: One more internet question please.
  • 38:44 - 38:50
    Q: Thank you. What if a rootkit doesn't
    fit in the SPI flash. Is filling up the
  • 38:50 - 38:55
    SPI flash space completely a valid
    prevention?
  • 38:55 - 39:02
    A: No I don't know... we could really call
    it a prevention mechanism. But yeah, if
  • 39:02 - 39:07
    there is not enough free space available
    on the firmware volumes the tool will just fail.
  • 39:09 - 39:11
    Herald: Number two please.
  • 39:11 - 39:17
    Q: Hi. You said that there is no real
    possibility to secure everything, but what
  • 39:17 - 39:23
    are your daily choices that you use like,
    on your personal computer, to be fully
  • 39:23 - 39:28
    secret?
    A: Well... laughing I could say an
  • 39:28 - 39:33
    alternative platform, but... laughter
    but yeah, if you have
  • 39:33 - 39:37
    a modern Intel CPU and you have
  • 39:37 - 39:43
    Secure Boot enabled and you have, you
    know, all of the latest UEFI firmware
  • 39:43 - 39:50
    updates, that's kind of the best you can
    do to be safe for... against that kind of
  • 39:50 - 39:53
    attack.
    Q: I have... I have my like this...
  • 39:53 - 39:57
    Herald: Number 1 please.
    Q: So, going back to the LoJack
  • 39:57 - 40:06
    configuration file vulnerability. Is the
    configuration file on the operating system
  • 40:06 - 40:10
    file system?
    A: No no no, the... In fact it's... there is
  • 40:10 - 40:16
    not a separate configuration file, the
    configuration is embedded inside the
  • 40:16 - 40:19
    executable. So it is embedded into
    rpcnetp.exe.
  • 40:21 - 40:26
    Herald: Unfortunately, we are already out
    of time. So please thank our speaker
  • 40:26 - 40:26
    again.
  • 40:26 - 40:30
    applause
  • 40:30 - 40:35
    postroll music
  • 40:35 - 40:53
    subtitles created by c3subtitles.de
    in the year 2019. Join, and help us!
Title:
35C3 - First Sednit UEFI Rootkit Unveiled
Description:

more » « less
Video Language:
English
Duration:
40:53

English subtitles

Revisions Compare revisions