The Heartbleed Bug, explained

There was big news in the computer security world yesterday when researchers announced a massive vulnerability in popular web encryption software called OpenSSL. Major online service providers are scrambling to address the problem. What happened? And how does it affect you? Read on to find out.

What’s SSL?

SSL is a popular encryption technology that allows web users to protect the privacy of information they transmit over the internet. When you visit a secure website such as, you’ll see a lock next to the URL, indicating that your communications with the site are encrypted. Here’s what that looks like in Google’s Chrome browser:

Screen_shot_2014-04-08_at_10That lock is supposed to signal that third parties won’t be able to read any information you send or receive. Under the hood, SSL accomplishes that by transforming your data into a coded message that only the recipient knows how to decipher. If a malicious party is listening to the conversation, it will only see a seemingly random string of characters, not the contents of your emails, Facebook posts, credit card numbers, or other private information.


SSL was first introduced by Netscape in 1994 and has been available for all major browsers since the 1990s. In recent years, there has been a trend toward major online services to using encryption by default. Today, Google, Yahoo, and Facebook all use SSL encryption by default for their websites and online services.

What is the Heartbleed Bug?

The majority of SSL-encrypted websites are based on an open-source software package called OpenSSL. On Monday, researchers announced a serious bug in this software that exposes users’ communications to eavesdropping. OpenSSL has had this flaw for about 2 years.

Here’s how it works: the SSL standard includes a heartbeat option, which allows a computer at one end of an SSL connection to send a short message to verify that the other computer is still online and get a response back. Researchers found that it’s possible to send a cleverly formed, malicious heartbeat message that tricks the computer at the other end into divulging secret information. Specifically, a vulnerable computer can be tricked into transmitting the contents of the server’s memory, known as RAM.

Is that bad?

Yes. There’s a lot of private information stored in a server’s memory. Ed Felten, a computer scientist at Princeton (and, disclosure, my former graduate advisor) says that attackers using the technique can “sort through that information by doing pattern matching to try to find secret keys, passwords, and personal information like credit card numbers.”

I don’t need to explain why exposing passwords and credit card numbers could be harmful. But exposing secret keys can be even worse. This is the information servers use to unscramble encrypted information it receives. If an attacker obtains a server’s private keys, it can read any information sent to it. It may even be able to use the secret key to impersonate the server, tricking users into divulging their password and other sensitive information.

Who discovered the problem?

It was discovered independently by researchers at Codenomicon and Google Security. To minimize the damage from the disclosure, the researchers worked with the OpenSSL team and other key insiders to prepare fixes before the problem was announced publicly.

Who can exploit the Heartbleed Bug?

“This vulnerability is not very difficult to exploit for those who know about it,” Felten tells me. Software to exploit the vulnerability is widely available online, and while the software isn’t as user-friendly as an iPad app, anyone with basic programming skills can figure out how to use it.


Of course, the bug is likely to be most valuable to intelligence agencies, which have the infrastructure to intercept user traffic on a mass scale. We know that the National Security Agency hassecret agreements with American telecommunications providers to tap into the Internet backbone. Users might have thought that the SSL encryption on websites such as Gmail and Facebook protected them from this kind of snooping. But the Heartbleed bug could allow the NSA to obtain the private keys needed to unscramble these private communications.

We don’t know for sure, but it wouldn’t be surprising if the NSA discovered the Heartbleed vulnerability before the general public did. OpenSSL is among the most widely used encryption software in the world, so it’s a safe bet that NSA security experts have gone through its source code with a fine-toothed comb.

How many sites are affected?

There aren’t precise statistics available, but the researchers who discovered the vulnerability note that the two most popular web servers, Apache and nginx, use OpenSSL. Together, these vulnerable servers account for about two-thirds of the sites on the web. SSL is also used by other internet software, such as desktop email clients and chat software.

The researchers who discovered the flaw notified the OpenSSL team and other key stakeholders several days ago. That allowed OpenSSL to announce a fixed version of the software at the same time the vulnerability was announced to the public. To address the problem, websites simply need to ensure they’re running the latest version of OpenSSL.


A Yahoo spokesperson tells us that “Our team has successfully made the appropriate corrections across the main Yahoo properties (Yahoo Homepage, Yahoo Search, Yahoo Mail, Yahoo Finance, Yahoo Sports, Yahoo Food, Yahoo Tech, Flickr and Tumblr) and we are working to implement the fix across the rest of our sites right now.”

Google says that “we have assessed the SSL vulnerability and applied patches to key Google services.” Facebook says it had already addressed the issue when it was publicly disclosed.

Finally, a Microsoft spokesman writes that “We are following reports of an OpenSSL library issue. If we determine there is an impact to our devices and services, we’ll take necessary steps to protect our customers.”

What can users do to address the problem?

Unfortunately, there’s nothing users can do to protect themselves if they visit a vulnerable website. The administrators of vulnerable websites will need to upgrade their software before users will be protected.

However, once an affected website has fixed the problem on their end, users can protect themselves by changing their passwords. Attackers might have intercepted user passwords in the meantime, and Felten says there’s probably no way for users to tell whether anyone intercepted their passwords.

Note: This post has been modified to include updated statements from Yahoo, Google, Microsoft, and Facebook. Also, the language was tweaked to make clear websites need run new OpenSSL software after installing it.


Zeus banking malware hides a crucial file in a photo

IDG News Service - A newly discovered variant of the notorious Zeus banking trojan is disguising a crucial configuration code in a digital photo, a technique known as steganography.

Zeus is one of the most effective tools to steal online banking details, hijacking login details as a person accesses his account and masking secret transfers in the background.

The variant, called ZeusVM, downloads a configuration file that contains the domains of banks that the malware is instructed to intervene in during a transaction, wrote Jerome Segura, a senior security researcher with Malwarebytes. He wrote the behavior was first noticed by a French security researcher who writes under the name Xylitol.

“The malware was retrieving a JPG image hosted on the same server as were other malware components,” Segura wrote.

Steganography has long been used by writers of malicious software. By embedding code in a file format that looks legitimate, there’s a chance the file will be given a green light by security software.

“From a webmaster point of view, images (especially ones that can be viewed) would appear harmless,” Segura wrote.

The suspect image appears to be much larger when compared to an identical one in bitmap mode, he wrote. The data added by the cybercriminals had been encrypted using Base64 encoding and then RC4 and XOR encryption algorithms.

When decrypted, the file shows the banks targeted, including Deutsche Bank, Wells Fargo and Barclays.



NSA BIOS Backdoor a.k.a. God Mode Malware

NSA BIOS Backdoor a.k.a. God Mode Malware Part 1: DEITYBOUNCE


This article is the first part of a series on NSA BIOS backdoor internals. Before we begin, I’d like to point out why these malwares are classified as “god mode.” First, most of the malware uses an internal (NSA) codename in the realms of “gods,” such as DEITYBOUNCE, GODSURGE, etc. Second, these malwares have capabilities similar to “god mode” cheats in video games, which make the player using it close to being invincible. This is the case with this type of malware because it is very hard to detect and remove, even with the most sophisticated anti-malware tools, during its possible deployment timeframe.

This part of the series focuses on the DEITYBOUNCE malware described in the NSA ANT Server document, leaked by Edward Snowden. The analysis presented in this article is based on technical implications of the information provided by the document. The document lacks many technical specifics, but based on the BIOS technology at the day DEITYBOUNCE started to become operational, we can infer some technically sound hypotheses—or conclusions, if you prefer :-).

Introduction to DEITYBOUNCE Malware

DEITYBOUNCE operates as part of the system shown in Figure 1. Figure 1 shows several peculiar terms, such as ROC, SNEAKERNET, etc. Some of these terms are internally used by NSA. ROC is an abbreviation for remote operation center. ROC acts as NSA’s point of control of the target system; it’s located outside NSA’s headquarter. SNEAKERNET is a fabulous term for physical delivery of data, i.e., using humans to move data between computers by moving removable media such asmagnetic tapefloppy diskscompact discsUSB flash drives (thumb drives, USB stick), or external hard drives from onecomputer to another.

Figure 1 DEITYBOUNCE Extended Concept of Operation

Figure 1 shows DEITYBOUNCE targeting the machines marked with red dot. DEITYBOUNCE itself is not installed on those machines because DEITYBOUNCE targets Dell PowerEdge 1850/2850/1950/2950 RAID server series with BIOS versions A02, A05, A06, 1.1.0, 1.2.0, or 1.3.7, not laptops or desktop/workstations. This means DEITYBOUNCE is installed in servers accessed by the laptops or desktop/workstations marked with red dots. The red dot also means that the target systems could act as “jump hosts” to implant DEITYBOUNCE in the target servers.

Want to learn more?? The InfoSec Institute Ethical Hacking course goes in-depth into the techniques used by malicious, black hat hackers with attention getting lectures and hands-on lab exercises. While these hacking skills can be used for malicious purposes, this class teaches you how to use the same hacking techniques to perform a white-hat, ethical hack, on your organization. You leave with the ability to quantitatively assess and measure threats to information assets; and discover where your organization is most vulnerable to black hat hackers. Some features of this course include:

  • Dual Certification - CEH and CPT
  • 5 days of Intensive Hands-On Labs
  • Expert Instruction
  • CTF exercises in the evening
  • Most up-to-date proprietary courseware available


Figure 1 also shows the presence of ARKSTREAM. ARKSTREAM is basically a malware dropper which contains BIOS flasher and malware dropper functions. ARKSTREAM can install DEITYBOUNCE on the target server either via exploits controlled remotely (network infection) or via USB thumb drive infection. This infection method, in a way, is very similar to the STUXNET malware dropper. ARKSTREAM installs DEITYBOUNCE via BIOS flashing, i.e., replacing the PowerEdge server BIOS with the one that is “infected” by DEITYBOUNCE malware.

The NSA ANT server document doesn’t divulge minute details explaining DEITYBOUNCE’s “technical context” of operation. However, we can infer some parts of the “technical context” from the DEITYBOUNCE technical requirements mentioned in the document. These are the important technical details revealed by the NSA ANT server document:

  1. DEITYBOUNCE provides software application persistence on Dell PowerEdge servers by exploiting the motherboard BIOS and utilizing system management mode (SMM) to gain periodic executions while the operating system (OS) loads.
  2. DEITYBOUNCE supports multiprocessor systems with RAID hardware and Microsoft Windows 2000, XP, and 2003 Server.
  3. Once implanted, DEITYBOUNCE’s frequency of execution (dropping the payload) is configurable and will occur when the target machine powers on.

In later sections, we will look into DEITYBOUNCE malware architecture in more detail, based on these technical details. These details provide a lot more valuable hints than you think :-). But before that, you need to have some important background knowledge.

A Closer Look at Dell Power-Edge Hardware

Let’s start with the first item of background knowledge. In the previous section, we learned that DEITYBOUNCE targets Dell PowerEdge 1850/2850/1950/2950 RAID server series. Therefore, we need to look into the servers more closely to understand the DEITYBOUNCE execution environment. One can download the relevant server specifications from these links:

  1. Dell PowerEdge 1950 specification:
  2. Dell PowerEdge 2950 specification:

The server specifications are rather ordinary. However, if you look more closely at the storage options of both server types, you’ll notice the option to use a RAID controller in both server types. The RAID controller is of the type PERC 5/i, PERC4e/DC, or PERC 5/e. We focus on the RAID controller hardware because DEITYBOUNCE technical details mentioned the presence of RAID as one of its hardware “requirements.”

Now let’s move into more detailed analysis. You can download the user guide for the Dell PERC family of RAID controller from:’s%20Guide_en-us.pdf. Despite the fact that the document is only a user guide, it provides important information, as follows:

  1. PERC stands for PowerEdge Expandable RAID Controller. This means the PERC series of RAID controller are either white-labeled by Dell or developed internally by Dell.
  2. There are several types of PERC RAID controllers. The ones with the XX/i moniker are the integrated versions, the XX/SC moniker means that the RAID controller is single channel, the XX/DC moniker means that the RAID controller is dual channel, and the XXe/XX moniker signifies that the RAID controller uses PCI Express (PCIe) instead of PCI bus. If the last moniker is missing, it implies that the RAID controller uses PCI, not PCIe.
  3. All PERC variants have 1MB of onboard flash ROM. Mind you, this is not the PowerEdge server motherboard flash ROM but the PERC RAID controller (exclusive) flash ROM. It’s used to initialize and configure the RAID controller.
  4. All PERC variants have NVRAM to store their configuration data. The NVRAM is located in the PERC adapter board, except when the PERC is integrated into the motherboard.

The PERC RAID controller flash ROM size (1MB) is huge from the firmware code point of view. Therefore, anyone can insert an advanced—read: large in code size—malicious firmware-level module into it.

I can’t find information on the Dell PowerEdge 1850/2850/1950/2950 BIOS chip size. However, the size of their compressed BIOS files is larger than 570KB. Therefore, it’s safe to assume that the motherboards BIOS chip size are at least 1MB because, AFAIK, there is no flash ROM chip—used to store BIOS code—that has a size between 570KB and 1MB. The closest flash ROM size to 570KB is 1MB. This fact also present a huge opportunity to place BIOS malware into the motherboard BIOS besides the RAID controller expansion ROM.

Initial Program Loader (IPL) Device Primer

The second item of background knowledge you need to know pertains to the IPL device. A RAID controller or other storage controller is an attractive victim for firmware malware because they are IPL devices, as per BIOS boot specification. The BIOS boot specification and PCI specification dictate that IPL device firmware must be executed at boot if the IPL device is in use. IPL device firmware is mostly implemented as PCI expansion ROM. Therefore, IPL device firmware is always executed, assuming the IPL device is in use. This fact opens a path for firmware-level malware to reside in the IPL device firmware, particularly if the malware has to be executed at every boot or on certain trigger at boot.

For more details on IPL device firmware execution, see: You need to take a closer look at the boot connection vector (BCV) in the PCI expansion ROM in that article. The system BIOS calls/jumps-into the BCV during bootstrap to start the bootloader, which then loads and executes the OS. BCV is implemented in the PCI expansion ROM of the storage controller device. Therefore, the PERC RAID controller in Dell PowerEdge servers should implement BCV as well to conform to the BIOS boot specification.

IPL device PCI expansion ROM also has a peculiarity. In some BIOS implementations, it’s always executed, whether or not the IPL device is being used. The reason is that the BIOS code very probably only checks for the PCI device subclass code and interface code in its PCI configuration register. See the “PCI PnP Expansion ROM Peculiarity” section at

System Management Mode (SMM) Primer

The third item of background knowledge needed to understand DEITYBOUNCE is SMM. A seminal work on SMM malware can be found in the Phrack ezine article, A Real SMM Rootkit: Reversing and Hooking BIOS SMI Handlers at SMI, in this context, means system management interrupt. The Phrack article contains knowledge required to understand how an SMM rootkit might work.

There is one thing that needs to be updated in that Phrack article, though. Recent and present-day CPUs don’t use high segment (HSEG) anymore to store SMM code. Only top-of-memory segment (TSEG) is used for that purpose. If you’re not familiar with HSEG and TSEG, you can refer to and for details on HSEG and TSEG location in the CPU memory space. This means, for maximum forward compatibility, DEITYBOUNCE very possibly only uses TSEG in its SMM component.

Entering SMM via software SMI in x86/x64 is quite simple. All you need to do is write a certain value to a particular I/O port address. A write transaction to this I/O port is interpreted by the chipset as a request to enter SMM, therefore the chipset sends an SMI signal to the CPU to enter SMM. There are certain x86/x64 CPUs that directly “trap” this kind of I/O write transaction and interpret it directly as a request to enter SMM without passing anything to the chipset first. The complete algorithm to enter SMM is as follows:

  1. Initialize the DX register with the SMM “activation” port. Usually, the SMM “activation” port is port number 0xB2. However, it could be a different port, depending on the specific CPU and chipset combination. You have to resort to their datasheets for the details.
  2. Initialize the AX register with the SMI command value.
  3. Enter SMM by writing the AX value to the output port contained in the DX register.

As for the methods to pass parameters to the SMI handler routine, it’s not covered extensively by the Phrack article. Therefore, we will have a look the methods here.

Some SMM code (SMI handler) needs to communicate with other BIOS modules or with software running inside the OS. The communication mechanism is carried out through parameter passing between the SMM code and code running outside SMM. Parameter(s) passing between the BIOS module and SMI handler in general are carried out using one of these mechanisms:

  1. Via the global non-volatile storage (GNVS). GNVS is part of ACPI v4.0 Specification and named ACPI non-volatile storage (NVS) in the ACPI specification. However, in some patent descriptions, NVS stands for non-volatile sleeping memory because the memory region occupied by NVS in RAM stores data that’s preserved even if the system is in sleep mode. Either term refers to the same region in RAM. Therefore, the discrepancies in naming can be ignored. GNVS or ACPI NVS is part of RAM managed by the ACPI subsystem in the BIOS. It stores various data. GNVS is not managed by the OS, but is reachable by the OS through the ACPI source language (ASL) interface. In Windows, parts of this region are accessible through the Windows management instrumentation (WMI) interface.
  2. Via general-purpose registers (GPRs) in x86/x64 architecture, i.e., RAX/EAX, RBX/EBX, RDX/EDX, etc. In this technique, a physical address pointer is passed via GPR to the SMI handler code. Because the system state, including the register values, is saved to the “SMM save state,” the code in the SMM area (the SMI handlers) is able to read the pointer value. The catch is: both the SMI handler and the code that passes the parameter(s) must agree on the “calling convention”, i.e., which register(s) to use.

Knowing parameter passing between BIOS module and SMI handler is important because DEITYBOUNCE uses this mechanism extensively when it runs. We will look into it in more detail in later sections.

Precursor to DEITYBOUNCE Malware Architecture

As with other software, we can infer DEITYBOUNCE malware architecture from its execution environment. The NSA ANT server document mentions three technical hints, as you can see in the Introduction section. We’ll delve into them one by one to uncover the possible DEITYBOUNCE architecture.

The need for RAID hardware means that DEITYBOUNCE contains a malware implanted in the RAID controller PCI expansion ROM. The RAID controller used in Dell PowerEdge 1950 server is the PERC 5/i, or PERC4e/DC, or PERC 5/e adapter card. All of these RAID controllers are either PCI or PCI Express (PCIe) RAID controllers. You have to pay attention to the fact that PCI expansion ROM also includes PCIe expansion ROM, because both are virtually the same. I have covered PCI expansion ROM malware basics in another article. See for the details.

The presence of a payload being dropped by DEITYBOUNCE means DEITYBOUNCE is basically a “second-stage” malware dropper—the first stage is the ARKSTREAM malware dropper. DEITYBOUNCE probably only provides these two core functions:

  1. The first is as a persistent and stealthy malware modules dropper.
  2. The second is to provide a “stealth” control function to other OS-specific malware modules. The malware modules could be running during OS initialization or from inside a running OS or the malware modules can operate in both scenarios. The OS-specific malware communicates with DEITYBOUNCE via SMM calls.

The DEITYBOUNCE core functions above imply that there are possibly three kinds of malware components required for DEITYBOUNCE to work as follows:

  1. A persistent “infected” PCI expansion ROM. This module contains a routine to configure DEITYBOUNCE’s frequency of execution. The routine possibly stores the configuration in the RAID controller NVRAM. This module also contains the tainted interrupt 13h (Int 13h) handler that can call other routines via SMI to patch the kernel of the currently loading OS.
  2. SMI handler(s) code implanted in the PowerEdge motherboard BIOS to serve the software (SW) SMI calls from the “infected” RAID controller PCI expansion ROM.
  3. An OS-specific malware payload running in Windows 2000, Windows Server 2003, or Windows XP.

At this point we already know the DEITYBOUNCE malware components. This doesn’t imply that we would be able to know the exact architecture of the malware, because there are several possible pathways through which to implement the components. However, I present the most probable architecture here. This is an educated guess. There could be inaccuracies because I don’t have a sample DEITYBOUNCE binary to back up my assertions. But I think the guesses should be close enough, given the nature of x86/x64 firmware architecture. If you could provide a binary sample with suspected DEITYBOUNCE in it, I’m open to analyze it, though :-).

DEITYBOUNCE Malware Architecture

We need to make several assumptions before proceeding to the DEITYBOUNCE architecture. This should make it easier to pinpoint the technical details of DEITYBOUNCE. These are the assumptions:

  1. The BIOS used by the Dell PowerEdge targets is a legacy BIOS, not EFI/UEFI. This assumption is strengthened by the NSA ANT server document, which mentions the target OS as Windows 2000/XP/2003. None of these operating systems provides mature EFI/UEFI support. All user manuals, including the BIOS setup user manual, don’t indicate any menu related to UEFI/EFI support, such as booting in legacy BIOS mode. Therefore, it’s safe to assume that the BIOS is a legacy BIOS implementation. Moreover, during the launch time of DEITYBOUNCE, EFI/UEFI support in the market is still immature.
  2. The custom SMI handler routines required to patch the OS kernel during bootstrap are larger than the empty space available in the motherboard BIOS. Therefore, the routines must be placed into two separate flash ROM storage, i.e., the PERC RAID controller flash ROM chip and the Dell PowerEdge motherboard flash ROM chip. This may be not the case, but let’s just make an assumption here, because even a rudimentary NTFS driver would require at least several tens of kilobytes of space when compressed, not to mention a complicated malware designed to patch kernels of three different operating systems.

The assumptions above have several consequences for our alleged DEITYBOUNCE architecture. The first one is that there are two stages in DEITYBOUNCE execution. The second one is that the malware code that patches the target OS kernel during bootstrap (interrupt 19h) is running in SMM.

Now let’s look into the DEITYBOUNCE execution stages. DEITYBOUNCE execution stages are as follows:

  1. Stage 1—PCI expansion ROM initialization during power-on self-test (POST). In this stage, DEITYBOUNCE installs additional malicious SMI handlers in the system management RAM (SMRAM) range in the RAM on the motherboard. The assumption here is that the SMRAM range is not yet locked by the motherboard BIOS, therefore the SMRAM range is still writeable. SMRAM is a range in system memory (RAM) that is used specifically for SMM code and data. Contents of SMRAM are only accessible through SMI after it has been locked. On most Intel Northbridge chipsets or recent CPUs, SMRAM is controlled by the register that controls the TSEG memory region. Usually, the register is called TSEG_BASE in Intel chipset documentation.
  2. Stage 2—Interrupt 13h execution during bootstrap (interrupt 19h). Interrupt 13h handler in the PERC RAID controller PCI expansion ROM is “patched” with malicious code to serve interrupt 19h invocation (bootstrap). Interrupt 19h copies the bootloader to RAM by calling interrupt 13h function 02h, read sectors from drive, and jump into it. DEITYBOUNCE doesn’t compromise the bootloader. However, DEITYBOUNCE compromises the interrupt 13h handler. The “patched” interrupt 13h handler will modify the loaded OS kernel in RAM.

Figure 2 shows stage 1 of DEITYBOUNCE execution and Figure 3 shows stage 2 of DEITYBOUNCE execution.

Figure 2 DEITYBOUNCE Execution Stage 1

DEITYBOUNCE stage 1 execution, shown in Figure 2, happens during the PCI expansion ROM initialization stage at POST. If you’re not familiar with the detailed steps carried out by the BIOS to initialize an x86/x64 system, a.k.a. power-on self-test, please read my system address map initialization on x86/x64 Part 1 article at

We know that PCI expansion ROM initialization is initiated by the motherboard BIOS from the Malicious Code Execution in PCI Expansion ROM article ( The motherboard BIOS calls the INIT function (offset 03h from start of the PCI expansion ROM) with a far call to start add-on board initialization by the PCI expansion ROM. This event is the stage 1 of DEITYBOUNCE execution. In the DEITYBOUNCE case, the add-on board is the PERC PCI/PCIe board or the PERC chip integrated with the PowerEdge motherboard.

Figure 2 illustrates the following execution steps:

  1. PERC RAID PCI expansion ROM executes from its INIT entry point.
  2. The infected ROM code reads DEITYBOUNCE configuration data from the RAID controller NVRAM.
  3. The infected ROM code copies DEITYBOUNCE’s additional SMI handlers to the SMRAM range in the motherboard main memory (system RAM).
  4. The infected ROM code fixes checksums of the contents of SMRAM as needed.

Once the steps above are finished, the SMRAM contains all of DEITYBOUNCE’s SMI handlers. Figure 2 shows that the SMRAM contains “embedded” DEITYBOUNCE SMI handlers that are already present in SMRAM before the DEITYBOUNCE component in the RAID controller PCI expansion ROM is copied into SMRAM. The embedded DEITYBOUNCE component is injected into the motherboard BIOS. That’s why it’s already present in SMRAM early on.

Figure 2 shows DEITYBOUNCE configuration data stored in the PERC add-on board NVRAM. This is an elegant and stealthy way of storing configuration data. How many anti-malware tools scan add-on board NVRAM? I’ve never heard of any.

Figure 3 DEITYBOUNCE Execution Stage 2

Now, let’s move to stage 2 of DEITYBOUNCE execution. There are several steps in this execution stage, as follows:

  1. The mainboard BIOS executes the PERC RAID controller PCI expansion ROM routine at bootstrap via interrupt 19h (bootstrap). This time the entry point of the PCI expansion ROM is its BCV, not the INIT function. Interrupt 19h invokes interrupt 13h function 02h to read the first sector of the boot device—in this case the HDD controlled by the RAID controller—to RAM and then jump into it to start the bootloader.
  2. The infected PCI expansion ROM routine contains a custom interrupt 13h handler. This custom interrupt handler executes when interrupt 13h is called by the bootloader and part of the OS initialization code. The custom routines contain the original interrupt 13h handler logic. But the custom one adds routines to infect the kernel of the OS being loaded. Interrupt 13h provides services to read/write/query the storage device. Therefore, a malicious coder can modify the contents of interrupt 13h handler routine to tamper with the content being loaded to RAM. Figure 3 shows that the custom interrupt 13h handler contains a routine to call the DEITYBOUNCE SMI handler via software SMI. The DEITYBOUNCE SMI handler contains a routine to install malware or to activate certain vulnerabilities in the target OS kernel while the OS is still in the initialization phase. Execution of the custom interrupt 13h handler depends on DEITYBOUNCE configuration data. Figure 3 DEITYBOUNCE configuration data related to the custom interrupt 13h handler is stored in the PERC RAID controller NVRAM.

The target OS contains a vulnerability or malware after steps 1 and 2 in DEITYBOUNCE second stage execution. Keep in mind that the vulnerability or malware only exists in RAM because the instance of the OS that’s modified by DEITYBOUNCE exists in RAM, not in a permanent storage device (HDD or SSD).

At this point we know how DEITYBOUNCE might work in sufficient detail. However, you should be aware that this is only the result of my preliminary assessment on DEITYBOUNCE. Therefore, it’s bound to have inaccuracies.

Closing Thoughts: Hypotheses on DEITYBOUNCE Technical Purpose

There are two undeniable strategic values possessed by DEITYBOUNCE compared to “ordinary” malware:

  1. DEITYBOUNCE provides a stealthy way to alter the loaded OS without leaving a trace on the storage device, i.e., HDD or SSD, in order to avoid being detected via “ordinary” computer forensic procedures. Why? Because the OS is manipulated when it’s loaded to RAM, the OS installation on the storage device itself is left untouched (genuine). SMM code execution provides a way to conceal the code execution from possible OS integrity checks by other-party scanners. In this respect, we can view DEITYBOUNCE as a very sophisticated malware dropper.
  2. DEITYBOUNCE provides a way to preserve the presence of the malware in the target system because it is persistent against OS reinstallation.

Given the capabilities provided by DEITYBOUNCE, there could possibly be a stealthy Windows rootkit that communicates with DEITYBOUNCE via software SMI to call the DEITYBOUNCE SMI handler routine at runtime from within Windows. The purpose of such a rootkit is unclear at this point. Whether the required SMI handler is implemented by DEITYBOUNCE is unknown at the moment.



Android one-click Google authentication method puts users, businesses at risk

A feature that allows Android users to authenticate themselves on Google websites without having to enter their account password can be abused by rogue apps to give attackers access to Google accounts, a security researcher showed Saturday at the Defcon security conference in Las Vegas.


Security researcher Craig Young talks at Defcon 21

Security researcher Craig Young presents Google ‘weblogin’ risks at Defcon 21 security conference.


The feature is called “weblogin” and works by generating a unique token that can be used to directly authenticate users on Google websites using the accounts they have already configured on their devices.

Weblogin provides a better user experience but can potentially compromise the privacy and security of personal Google accounts, as well as Google Apps accounts used by businesses, Craig Young, a researcher at security firm Tripwire, said during his talk.

Young created a proof-of-concept rogue app that can steal weblogin tokens and send them back to an attacker who can then use them in a Web browser to impersonate a victim on Google Apps, Gmail, Drive, Calendar, Voice and other Google services.

The app was designed to masquerade as a stock viewing app for Google Finance and was published on Google Play, with a description that clearly indicated it was malicious and shouldn’t be installed by users.

During installation, the app asks for permission to find accounts on a device, use the accounts on a device and access the network. When run, it then displays another prompt asking for permission to access a URL that starts with “weblogin” and includes

This secondary prompt is uninformative and most users are likely to accept the request, Young said.

If they do, a weblogin token is generated and the users are automatically signed in to the Google Finance website. However, at the same time, the token is siphoned off through an encrypted connection to a server controlled by the attacker.

The issue is that this weblogin token does not only work for Google Finance, but for all Google services, Young said.

For example, it can provide access to the victim’s documents in Google Drive, emails in Gmail, calendar entries in Google Calendar, Google Web search history or potentially sensitive company data stored in Google Apps, the researcher said.

It can also be used to access a user’s Google Play account and remotely install apps on his device or to access his accounts on third-party websites that support Google Federated Login.

If the user is an administrator for a company’s Google Apps domain, the attack could compromise the company’s entire Google Apps operation. The attacker would gain the ability to reset the passwords for other users on that Google Apps domain, create and modify privileges and roles, create and modify mailing lists, and even add new users with administrative privileges, the researcher said.

The issue was reported to Google in February and the company started blocking some of the things an attacker could do, Young said.

For example, an attacker authenticated via a weblogin token can no longer use the Google Takeout service to get a data dump for an entire Google Account and can no longer add new Google Apps users, although there is a workaround that still makes the latter action possible, Young said.

Young’s app displays the weblogin permission prompt because it uses the standard Android API (application programming interface) to get the token. However, if the app used an exploit to get root privileges on the device, it would be able to grab the token without requiring user confirmation, he said.

The app stayed in Google Play for around a month until someone probably reported it as malicious, and during this time there was no indication it had been scanned by Bouncer, a Google Play service that searches for malicious apps in the marketplace, the researcher said. If it was scanned, then it wasn’t flagged as malicious, which raises questions about Bouncer’s effectiveness, he said.

After it was reported as malicious, the app was removed from Google Play, and Android’s local app verification feature now blocks it as spyware when trying to install it.

Google did not respond to a request for comment sent Thursday.

Most Android antivirus products from well known vendors didn’t detect the app as malware either, but one privacy advisor application did list the rogue app as having account access, Young said.

“Today’s presentation showed that with enough ingenuity and effort you can easily bypass apparently well protected systems,” said Alexandru Catalin Cosoi, the chief security strategist at antivirus vendor Bitdefender, who attended Young’s talk.

The only way to prevent these things from happening is to raise the cost of attacks, so that by the time one lock is bypassed, there is a new lock in place that needs to be breached, Cosoi said. Vulnerabilities can be found on a regular basis, so continuous research definitely helps in improving systems like Google Bouncer, making attacks more costly for hackers to pull off, he said.

Businesses shouldn’t allow their IT administrators to use Google accounts on their Android devices that are also Google Apps domain administrators, Young said.

Users should be wary of apps that request access to accounts added on the device and should answer “no” to permission prompts containing the words “weblogin” or “ID,” he said.

Google should create an option to allow Google Apps domain owners to block Google Apps access via weblogin and should make the weblogin prompts more informative so that users understand what they do, the researcher said.

“Hand of Thief” banking trojan doesn’t do Windows—but it does Linux



       The administration panel for Hand of Thief.


Signaling criminals’ growing interest in attacking non-Windows computers, researchers have discovered banking fraud malware that targets people using the open-source Linux operating system.

Hand of Thief, which was recently discovered by researchers from security firm RSA, sells for about $2,000 in underground Internet forums and boasts its own support and sales agents. Its functionality—consisting of form grabbers and backdoor capabilities—is rudimentary compared to Windows banking trojans spawned from the Citadel or Blackhole exploit kits, but that’s likely to change. RSA researcher Limor Kessem said she expects Hand of Thief to become a full-blown banking trojan that includes more advanced features such as the ability to inject attacker-controlled content into trusted bank webpages.

“Although Hand of Thief comes to the underground at a time when commercial trojans are high in demand, writing malware for the Linux OS is uncommon, and for good reason,” Kessem wrote. “In comparison to Windows, Linux’s user base is smaller, considerably reducing the number of potential victims and thereby the potential fraud gains.”

She also said that the open-source model Linux is developed on makes the OS less susceptible to attacks that remotely execute malicious code by exploiting security bugs. That viewpoint is popular among many open-source advocates, but it’s also the source of heated debates among security researchers. The number of Linux machines running Apache and other Web servers that are infected by Darkleech and similar exploits—recently estimated to be in the 20,000 range—suggests the platform isn’t out of the reach of motivated attackers. What’s more, contrary to popular beliefs, serious Linux vulnerabilities can sometimes linger for years. In fairness to Kessem, she said a Hand of Thief sales agent recently suggested using social-engineering attacks to infect users of the open-source OS.

Leaving that debate aside, Hand of Thief developers said the trojan has been tested on 15 different Linux desktop distributions, including Ubuntu, Fedora, and Debian. They also said it supports eight environments, including Gnome and Kde. The malware functions include a form grabber for both HTTP and HTTPS sessions running on Firefox, Google Chrome, and a host of Linux-only browsers. The trojan also blocks infected machines from accessing addresses that offer security updates and antivirus software. It contains defenses to prevent it from running on virtual machines to make it harder to be reverse engineered by white hat hackers and competitors.

“The developer wrote a basic administration panel for the trojan, allowing the botmaster to control the infected machines reporting to it,” Kessem wrote. “Captured data includes information such as timestamp, user agent, website visited and POST data. Hand of Thief also exhibits cookie-stealing functionality.”

The $2,000 price tag strikes Kessem as overpriced compared with Windows trojans. That may be true. But given the large number of security-conscious computer users who regard Linux as a relatively hacker resistant haven, Hand of Thief marketers may position it as a premium service for attacking high-value targets who can’t be penetrated otherwise. Further, given the vast improvements Microsoft has made in the past six years securing recent versions of Windows, malware writers may be interested in expanding the range of machines they can attack. Researchers recently unearthed a new banking trojan targeting Android users.

On the other hand, there are few if any reports of comparable malware targeting Mac users. It’s hard to know precisely what to make of Hand of Thief, but it’s worth keeping an eye on.

‘KeyBoy’ Malware Used in Targeted Attacks in Asia

A spate of attacks targeting users in Vietnam and India are infecting users with a backdoor designed to steal massive amounts of information.

According to researchers with Rapid7, the targeted attacks are using a malicious Microsoft Word document that exploits vulnerabilities in Microsoft Office to compromise computers with malware known as KeyBoy.

Specifically, the malicious attachments exploit CVE-2012-0158 and CVE-2012-1856, which were both patched by Microsoft in the MS12-027 and MS12-60 bulletins, respectively. The first document is written in Vietnamese, and is about “reviewing and discussing best practices for teaching and researching scientific topics,” Rapid7 researcher Claudio Guarnieri explained in a blog post.

The second document is written in English, and is related to the telecommunications infrastructure in Calcutta, India, including the coverage of GSM networks and availability and stability of broadband connections. Other attacks related to the campaign appear to have targeted at Taiwan, certain ethnic groups in China and various Western diplomats located abroad.

“We don’t know how many people have been infected in this attack,” Guarnieri toldSecurityWeek via email, explaining the company has only been able to identify some attacks as part of a campaign that is “long-running and very prolific.”

“From what we can tell, the victims seem to be diversified: academics, telecommunication corporations, diplomats and politicians,” he added.

Once opened, the documents install KeyBoy, so-named after a string present in one of the malware samples. KeyBoy works by registering a new Windows service known as MdAdum. At that point, the dropper launches the service with the DLL located at C:\WINDOWS\system32\CREDRIVER.dll and deletes itself.

According to Rapid7, the malware steals credentials from the local storage of Internet Explorer and Mozilla Firefox, and installs a keylogger for stealing data from Google Chrome.  The malware also enables the attackers to poke through the compromised computers in other ways and exfiltrate data.

“Recently the growth of amount and scale of targeted attacks has come to the point were they are starting to look more like opportunistic carpet bombings rather than ninja strikes,” Guarnieri blogged. “It’s common to observe attacks pulled off successfully without any particular sophistication in place, including the incidents described in this post.”

“Beware though, just because these attacks are conceptually targeted, it doesn’t necessarily mean that they should have a higher priority than any other threat on your security program,” the researcher added. “Our suggestion remains the same: identify your core assets, recognize the most impactful threats to such assets and inform and protect yourself accordingly.”

A more detailed analysis of the malware can be found here.

Microsoft Unveils Three Bug Bounty Programs for Win 8.1, IE 11 Previews

Microsoft Dangles “Mitigation Bypass Bounty” of $100,000 for Exploit Techniques That Can be Used Against Windows

Microsoft will pay security researchers for issues they uncover in the preview versions of Windows 8.1 and Internet Explorer 11 (IE11) as part of its own bounty program.

Microsoft announced three different programs on Wednesday, but only the program for IE11 matches the structure of a traditional bug bounty program. The other two focuses on getting researchers to work on “truly novel exploit techniques” that could bypass existing defenses in Windows 8.1 preview, and new defensive methods that could block exploitation techniques,Katie Moussouris, a senior security strategist lead at Microsoft Trustworthy Computing, toldSecurityWeek. The programs all kick off next week, on June 26, when the previews versions of IE11 and Windows 8.1 become available.

Microsoft Bug Bounty ProgramMicrosoft is “committed to security from ground up,” and the goal is to have “secure products before they’re even released,” Moussouris said. The final version of Windows 8.1 is not expected before the end of the year.

The Mitigation Bypass Bounty is “seeking holes in the shield,” Microsoft said, and will offer researchers$100,000 a piece for truly novel exploit techniques that can be used against the latest publicly available of version, beginning with Windows 8.1 preview, Moussouris said. This refers to techniques that are unknown to Microsoft and are not currently unused in the wild against other products.

The methods must be reliable, reasonable, generic—applicable to one or more common memory corruption vulnerability classes—and impactful, meaning they affect high-risk applications such as browsers and document readers, according to Microsoft’s submission guidelines.

Attackers use return-oriented programming techniques to defeat Data Execution Prevention (DEP) and address space layout randomization (ASLR) in various products. This program will help security teams get ahead of new tricks attackers may employ, Moussouris said.

The BlueHat Bonus for Defense offers researchers $50,000 per technical whitepaper which describes a defensive idea that could “effectively block an exploitation technique.” This program focuses on creating new defenses that can block bypasses for the latest publicly available version of Windows, beginning with Windows 8.1 preview.

The IE11 Preview Bug Bounty program “is all about the vulns [vulnerabilities],” Moussouris said. Researchers will be paid up to $11,000 per critical vulnerability identified over a 30-day period, from June 26 to July 26. The critical issues have to affect IE11 running on Windows 8.1 preview.

There will be four tiers in the IE11 program. ASLR information disclosure vulnerabilities will pay out approximately $500, and design-level flaws, issues with privacy implications, and sandbox escape vulnerabilities will likely pay $1,100. Remote code execution vulnerabilities can net researchers the maximum payment of $11,000, or even more if the RCE flaw can also escape the sandbox, according to Microsoft.

While Microsoft’s own security team will verify each submission, as soon as vulnerability or exploit has been verified, the researcher will be paid, Moussouris said. Researchers will not have to wait till Microsoft figures out how to mitigate the issues.

Unlike many of its counterparts in the industry, Microsoft has never really embraced the concept of offering bug bounties for vulnerability research. While Google has doled out thousands of dollars each quarter to researchers for finding vulnerabilities in its Chrome Web browser, and Mozilla Foundation for its Firefox browser and Thunderbird email client, Microsoft has generally chosen to work with developers directly without the bug bounty structure.

Microsoft’s “researcher engagement” over the past 10 years included sending the company’s security team to Poland to meet with the people who discovered the Blaster worm back in 2003, launching Blue Hat briefings, and awarding $260,000 in cash prizes as part of the BlueHat competition last year, she said. Microsoft has awarded penetration testing contracts to researchers in the past to collect vulnerability information in certain products.

In recent years, many researchers have stopped reporting security issues directly to Microsoft and have started working with various vulnerability “brokers” who typically pay out generous amounts in exchange for these reports, Moussouris said. Microsoft didn’t have a problem with this shift, except for one thing. These brokers generally are not interested in information about products that have not yet been released but are available in preview. Microsoft was concerned that these beta products were not getting necessary researcher attention to ensure serious vulnerabilities are identified and fixed before the final release.

This is where the three bounty programs come in. While Microsoft will continue to engage with researchers on security topics, there are many who are not able to take penetration testing contracts or otherwise work with Microsoft on a formal basis. The programs will broaden the group of available testers and bring in more people, Moussouris said.

At the end of the day, it’s about “getting the vulnerability as early in the process as possible,” said Moussouris.

Google Expands Transparency Report to Map Malicious Websites

SAN FRANCISCO – Google expanded its Transparency Report on Tuesday to include maps of spots around the world where hackers are laying traps or baiting Internet users.

“Two of the biggest threats online are malicious software that can take control of your computer, and phishing scams that try to trick you into sharing passwords or other private information,” Google engineer Lucas Ballard said in a blog post.

“So today we’re launching a new section on our Transparency Report that will shed more light on the sources of malware and phishing attacks.”

Information for the new section comes from a Safe Browsing program Google launched in 2006 to warn Internet travelers when they were heading for trouble such as bogus bank websites or pages booby-trapped with computer viruses.

“We’re currently flagging up to 10,000 sites a day, and because we share this technology with other browsers there are about one billion users we can help keep safe,” Ballard said.

The new section added at included a map that showed that “malware” hotspots include India and Central Europe.

Google’s Transparency Report also provides information about government requests around the world for information from the California-based Internet giant and demands for removal of content from online properties.

Last week, Google said that it asked a special US court handling national security investigations for permission to publish more open with the public about numbers of requests.

The court filing in Washington came amid a firestorm of protests over revelations that the National Security Agency had accessed vast amounts of data in a surveillance program under the supervision of the secret court.

How strong is your password? რამდენად ძლიერ პაროლს ხმარობთ?

კომპანია ინტელი თავის საიტზე გვთავაზობს შევამოწმოთ პაროლის სიძლიერე, იქვე გვიწერს რა დრო დაჭრდება თანამედროვე ტექნოლოგიებს მის გამოსაცნობად.

Microsoft issues replacement for botched patch

Microsoft is now issuing a replacement patch for a fix that was shelved two weeks ago after customersreported problems resulting after they installed it.

The new update, KB2840149, addresses the vulnerability described in bulletin MS013-036. It corrects three privately reported vulnerabilities, rated “important” in the Kernel-Mode Driver, which, if exploited by attackers, could grant them elevated privileges.

In a blog post Tuesday, Dustin Childs, group manager of response communications at the Microsoft Security Response Center, said of the new patch: “If you have automatic updates enabled, you won’t need to take any actions. For those manually updating, we encourage you to apply this update at your earliest convenience.”