BlueBorne Able to Affect Amazon Echo and Google Home


Approximately two and a half months ago Armis, an Internet of Things (IoT) cybersecurity research company, disclosed BlueBorne – Bluetooth implementation vulnerabilities that affected Windows, Android, Linux, and iOS devices. These Bluetooth vulnerabilities ultimately allow an attacker to remotely execute code, obtain sensitive information, or conduct man-in-the-middle (MitM) attacks against these devices. Recently, Armis discovered that around a total of 20 million Amazon Echo and Google Home, smart speaker voice-activated personal assistant IoT devices, are also susceptible to MitM BlueBorne attacks. According to Armis, Amazon Echo devices are vulnerable to CVE-2017-1000251: Linux Kernel Bluetooth Stack Overflow and CVE-2017-1000250: Sessions Description Protocol (SDP) Server Bluetoothd Process Sensitive Information Disclosure. The Google Home devices are vulnerable to CVE-2017-0785: Android Bluetooth Stack Sensitive Information Disclosure.

Attack Process

Picture taken from Armis

The YouTube Proof of Concept (PoC) video that Armis provided demonstrates a generic attack process for remotely exploiting an Amazon Echo device. First a malicious actor would launch a custom script that takes advantage of the BlueBorne vulnerability using the Bluetooth Media Access Control (MAC) address of the Echo device. The malicious actor would then be connected and running the device on the highest permission level of root. From this point on, the malicious actor could upload a file onto the Echo device by having it transferred on a specified port using the Netcat command. Once the file has been uploaded and mounted, the Echo device would take the input and apply it without any warning. In the video above, the PoC showed that the personal assistant on the Echo, Alexa, was reprogrammed to say that she has been hacked when someone says “Alexa”.


The Bluetooth features native on Amazon Echo and Google Echo are unable to be disabled. Both smart speaker personal assistant devices are also incompatible with antivirus software. These restrictions make it difficult to prevent or mitigate system device vulnerabilities, so the only known mitigation is to hope that Amazon and Google provide software patches that address vulnerabilities. The good news is that these two IoT devices automatically receive and install software updates. For the Amazon Echo, users can verify that their device has been patched by having a version newer than v591448720. Armis did not specify which version of Google Home is secure from the BlueBorne attack, so it is best to have the most current updates applied. Armis also has a BlueBorne vulnerability scanner available on the Google Play Store that scans nearby devices for devices vulnerable to the attack, so that users can apply software updates to mitigate the vulnerabilities.


Common Vulnerabilities and Exposures (CVE):


Echo and Home Articles and Advisory:

Android Vulnerabilities Patched

Last week on November 6, Google released patches for several vulnerabilities with their Android devices as a part of their monthly bulletin system update. The patches released this month address around 30 vulnerabilities for Android devices, which are separated into the three levels 2017-11-01, 2017-11-05, 2017-11-06 on Android’s advisory. These levels patch the common vulnerabilities remote code execution, elevation of privilege, information disclosure, and the recent Key Reinstallation Attack (KRACK) vulnerability that affects the WiFi Protected Access 2 (WPA2) Internet protocol. Patches for these vulnerabilities can also be found at the Android Open Source Project (AOSP) Google Git repository.

2017-11-01 patch 

Picture taken from Android

The first level Android posted on their monthly security bulletin addresses Elevation of Privilege (EoP), Remote Code Execution (RCE), and Information Disclosure (ID) vulnerabilities. These vulnerabilities are with Android’s Framework, Media Framework, and System. The patches have their associated Common Vulnerabilities and Exposures (CVE) number and AOSP Git repository links to patch the vulnerability listed in the picture above.

2017-11-05 patch 

Picture taken from Android

The second level Android posted on their monthly security bulletin addresses EoP, RCE, ID vulnerabilities. These vulnerabilities are with Android’s Kernel, MediaTek, NVIDIA, and Qualcomm system components. The patches have their associated Common Vulnerabilities and Exposures (CVE) number and AOSP Git repository links to patch the vulnerability listed in the picture above.

2017-11-06 patch 

Picture taken from Android

The third level Android posted on their monthly security bulletin addresses EoP vulnerabilities. The main purpose that these patches are in a separate level is due to specifically patching the recently disclosed KRACK vulnerability with the systems that utilize WPA2. The patches have their associated Common Vulnerabilities and Exposures (CVE) number and AOSP Git repository links to patch the vulnerability listed in the picture above as well.


Advisory and Article:

Android Open Source Project:

Google “Buganizer” Bugs

Picture taken from freeCodeCamp

Google employees utilize an online tool called Google Issue Tracker, otherwise referred to as the Buganizer System by Google employees, to track every bug and potential new feature with product development. This tool is also utilized by partners outside of Google that collaborate with each other on certain projects and to public users who were given access to use the Issue Tracker with their project. Anyone with an email account can also open their own tickets to report bugs with Google tools or view a list of open tickets referring to current bugs and feature requests by typing in “Status: Open” on their website. However, Gmail account users are unable to see further details about the status of an opened ticket such as displaying the bugs and work being done to resolve the issue with a time estimate. On October 30, bug bounty hunter Alex Birsan posted an analysis of how he exploited Google’s Buganizer System that earned him around $16,000 in payouts from Google’s bug bounty program.

Obtaining an Address

Picture taken from freeCodeCamp

In order to read further details on the progress of a bug resolution or new feature, a person would need to sign in with an email address with an email extension. The email format that would respond to the ticket tracking system would be set as The componentID section of the email would specify the category that a bug or feature belongs to, such as the number representing the vulnerability reports section of bugs. The issueID section of the email would specify the thread that an employee or specially granted person is responding to. Any Gmail user should not be able to create a email address, but according to bug bounty hunter Alex Birsan, he was able to do so. Birsan was able to create a Google email by signing up for a regular email address, ignoring the confirmation email, changing his email address to an address, then clicking on the confirmation link sent by Google to confirm the creation of his newly created email address. Birsan submitted the details on this vulnerability to Google, which they accepted the vulnerability within 11 hours and awarded him $3,133.7.

Ticket Notification Vulnerability

Picture taken from freeCodeCamp

An owner of an email extension has the ability to star the topics that are of interest to them to receive update notifications of the status of the ticket to their email. Birsan was able to confirm that an attacker could receive email notifications for the tickets that they modify the issueID of for a few thousand tickets, which would be forwarded to their Gmail account. Although an attacker could receive email notifications on ticket updates, they would only be able to receive notifications on the tickets relating to translating languages at the time of this writing. Regardless, Birsan submitted his report to Google, which they accepted within 5 hours and awarded him $5,000.

Sensitive Information Disclosure

Picture taken from freeCodeCamp

According to Birsan’s analysis, an attacker could retrieve the complete details regarding to any ticket in the database by specifying the issueIds’s section in a block of code he found in a Javascript file that was linked to an Application Programming Interface (API) of the application. The attacker could modify this section of code and sent it via an Hypertext Transfer Protocol (HTTP) web POST request. From this point on, an attacker could monitor the updates of tickets in the vulnerability reports section to exploit them before they are patched. Although this is considered a severe sensitive exposure of information, an attacker would have to spend a lot of time sifting through thousands of email notifications in order to find a vulnerability to exploit. Google also usually patches severe vulnerabilities within one hour, so this vulnerability is actually harder than it looks to successful take advantage of. Google accepted this vulnerability and disabled the feature within an hour of Birsan’s submission and awarded him $7,500.


Buganizer Analysis:

Google Issue Tracker:

Bug Tracker Articles:

HomeHack: Hacking LG Smart Appliances

The rise of common appliance devices connected to the Internet, otherwise known as Internet of Things (IoT) devices, have made people’s lives convenient. They allow people the ability to control devices such as washing machines, dryers, refrigerators, air conditioners, etc from remote locations. Although IoT devices have made people’s lives convenient, it also makes it convenient for malicious attackers to take advantage of its capabilities with the remote attack surface. In fact, cybersecurity company Check Point disclosed a vulnerability on October 26 that they refer to as HomeHack. This vulnerability is with an IoT application owned by tech giant (LG) – commonly referred to as Life’s Good – called SmartThinQ.

Client-Side Vulnerability

According to researchers at Check Point, LG’s SmartThinQ application was vulnerable to a passive vulnerability on the client side of the application. This allowed the researchers to remotely take control of a user’s SmartThinQ account and all of the IoT devices the user owns and has linked to their account. One of the devices they decided to take control of was an automated home vacuum cleaner produced by LG called Hom-Bot. This is a multipurpose device which was designed to clean the homeowners rooms and act as a security device, since it has a built-in camera that displays a real-time video feed as it cleans.

Attack Process

Picture taken from Check Point

Picture taken from Check Point

SmartThinQ source code is able to be returned when a user utilizes an Android Debug Bridge (ADB), according to Check Point. The malicious user could modify two sections of code to permit a rooted device from running the application by deleting the finish() function at the bottom of both sections.

The malicious user could then modify a section of code that was responsible for implementing Secure Sockets Layer (SSL) pinning to prevent application traffic from being intercepted. Check Point did not specify how they patched it, but it seems likely that removing the block of code would work. Once the SSL pinning mechanism was bypassed, an attacker could intercept application traffic with their proxy to send their own login request.


The researchers utilized the source code and discovered that the login process is as follows:

  1. Authentication request – verifies user credentials.
  2. Signature request – creates a signature based on the username from authentication request.
  3. Token request – use the signature response as a header and username as parameter to get access token for the user account.
  4. Login request – sends the access token in order to login to the application.

Finally, the malicious could then craft their own request on the intercept to use their own LG account username and then switch it to the victim’s username on steps 2 and 3, since the application does not depend on step 1, to login to their account.

Secure Application Version

The HomeHack vulnerability was addressed by LG when they released application update version 1.9.23 at the end of September. Researchers at Check Point suggest that SmartThinQ application users update their application version to the latest version, which is 1.9.24 at the time of this writing. It is suggested that versions below 1.9.23 are vulnerable to the HomeHack attack surface, so it is a best practice to keep the application up-to-date. Check Point researchers also suggest that LG smart appliance owners update their physical devices with the most recent versions.


CheckPoint Analysis:

LG Smart ThinQ Info:

HomeHack Articles:


Vulnerable BlackBerry Workspaces Server API

BlackBerry Workspaces Server is a system designed for system administrators to manage workspaces, devices, and users. A recent vulnerability with this service involves taking advantage of an Application Programming Interface (API) with the service. An API is a set of subroutine definitions, protocols, and tools for building application software in computer systems. Gotham Digital Services (GDS), a cybersecurity research company,  disclosed two vulnerabilities with this service to the public on October 16 with the coordination of BlackBerry. There are two vulnerabilities with the API inside BlackBerry Workspaces that allow an attacker to submit an unauthenticated request to eventually allow remote code execution on the server. These vulnerabilities are tracked as CVE-2017-9368Sensitive Information Disclosure, with a Common Vulnerability Scoring System version 3 (CVSSv3) of 4.3, and CVE-2017-9367Directory Traversal, with a CVSSv3 of 8.1.

Secure and Vulnerable Versions

GDS originally disclosed the vulnerabilities to BlackBerry on May 10, 2017. BlackBerry requested GDS to keep the vulnerabilities between each other until they could patch the vulnerabilities. Eventually, BlackBerry released an advisory for system administrators using the Workspaces Server components that are affected by these vulnerabilities, which are:

  • Appliance-X versions 1.11.2 and earlier
  • vApp versions 5.6.0 to 5.6.6
  • vApp versions 5.5.9 and earlier

The Workspaces Server components that are unaffected by these vulnerabilities are:

  • Appliance-X version 1.12.0 and later
  • Appliance-X versions on the 1.11 codeline: versions 1.11.3 and later
  • vApp version 5.7.2 and later
  • vApp versions on the 5.6 codeline: versions 5.6.7 and later
  • vApp versions on the 5.5 codeline: versions 5.5.10 and later


Sensitive Information Disclosure

Picture taken from GDS

Eric Rafaloff, a researcher for GDS, discovered a vulnerability in BlackBerry Workspaces Server that allowed the source code for the application to be revealed. This involved sending an unauthenticated Hypertext Transfer Protocol (HTTP) GET web request to the file path: /fileserver/main.js. Although this is a simple vulnerability to be exploited, an attacker would need to have knowledge of the BlackBerry Workspaces Server file system format and have access to the network that the server is running on. Once the attacker has access to the source code, they could tailor their next attack based off of vulnerabilities with the code. 

Directory Traversal

Picture taken from GDS

Picture taken from GDS


Using the returned source code of the application, Rafaloff discovered a directory traversal vulnerability that could be abused to upload files, such as a file containing code for a command prompt shell. This involved using a similar method as previously discussed in sensitive information disclosure, but to a different file path using a POST web request. Rafaloff found that the API, saveDocument, allowed unauthenticated file uploads to the web server. An attacker could exploit this vulnerability by sending a POST request to /fileserver/saveDocument to upload a file, such as shell.jsp, to /../../mnt/filespace/0/whiteLabel/. Once the file containing the shell code is uploaded, the attacker could then send commands to /whiteLabel/shell.jsp?cmd=(insert command here), through the GET web request to the web server.


BlackBerry Workspaces Services:

Server CVEs:

Vulnerability Write-ups:

Windows DNS Buffer Overflow

The Domain Name System (DNS) is a protocol that every computer uses to makes hard-to-remember Internet Protocol (IP) addresses, like, into something easier for a human to remember, like When you type into your web browser, it goes to a DNS server to be translated to, so that your request is redirected to the proper website, as every website has a specific IP address linked to it. Every computer system, including the Windows Operating System (OS), uses this protocol. In a recent study done by researchers at Bishop Fox, a cybersecurity consultation firm for Fortune 1000 companies, discovered a vulnerability in DNS with Windows 8 and 10 OSes that allows remote code to be executed. This was one of around 60 vulnerabilities that Microsoft had patched on October 10 as a part of Patch Tuesday.

Improper DNS Handling

The vulnerability that affects Windows 8 and 10 OSes is tracked as CVE-2017-11779: Windows DNSAPI Remote Code Execution Vulnerability. Researchers at Bishop Fox had found that this vulnerability is present with the way a Windows process called DNSAPI.dll handles DNS responses. Most notably, the vulnerability is able to be exploited by an attacker modifying a legitimate NSEC3 a Resource Record (RR), in Domain Name System Security Extensions (DNSSEC) that prevents DNS spoofing attacks by authenticating a denial of existence in invalid IP addresses, to return memory addresses on the target system, commonly referred to as a buffer overflow. According to Bishop Fox, the improper parsing of a function called Nsec3_RecordRead results in an out-of-bounds write. DNSAPI.dll also is used by a DnsCache service running under the common name of svchost.exe as NT AUTHORITY\NETWORK SERVICE user.

Modified Packets

Picture taken from Bishop Fox

Picture taken from Bishop Fox

Picture taken from Bishop Fox

An attacker is able to achieve an out-of-bounds read and write by overflowing three specific heaps. These heaps are within the same packet of the NSEC3 RR and are Data Length, Salt Length, and Hash Length, which results in an Integer Underflow. The data length could be modified to 255 (0xff), which would have 6 (0x6) subtracted to equal 249 (0x00f9). The hash length could be set to 248 (0xf8) and the salt length to 6 (0x6), which when cumulatively subtracted, equals -5 then gets under-flowed to equal 65531. This value is the number of bytes that will be returned from the function memcpy, which could be overwritten to include custom code to redirect to code for a command prompt shell – resulting in allowing arbitrary code execution.


Affected Systems and Patches

Microsoft has released system patches on October 10 to correct the way that DNSAPI.dll handles DNS responses. The systems that are all critically affected by this vulnerability and have patches for it run DNSAPI.dll version 6.3.9600.18512, for Windows 8.1 x86, and version 10.0.14393.206, for Windows 10 x64:

  • Windows 10 for 32-bit Systems
  • Windows 10 Version 1511 for 32-bit Systems
  • Windows 10 Version 1511 for x64-based Systems
  • Windows 10 Version 1607 for 32-bit Systems
  • Windows 10 Version 1607 for x64-based Systems
  • Windows 10 Version 1703 for 32-bit Systems
  • Windows 10 Version 1703 for x64-based Systems
  • Windows 8.1 for 32-bit systems
  • Windows 8.1 for x64-based systems
  • Windows RT 8.1
  • Windows Server 2012
  • Windows Server 2012 (Server Core installation)
  • Windows Server 2012 R2
  • Windows Server 2012 R2 (Server Core installation)
  • Windows Server 2016
  • Windows Server 2016 (Server Core installation)


Bishop Fox Analysis:

DNS CVE and Patch:


Windows DNS Articles:

Intel Boot Guard Bypass

The Unified Extensible Firmware Interface (UEFI) and Basic Input/Output System (BIOS) are firmware interfaces that interact with the Operating System (OS) and computer firmware in modern computers. These features are used every time a computer system is powered on in order to start the hardware components and load the operating system from the hard drive. The well known Information Technology (IT) company, Intel, has their own implementation to protect the boot-up feature from been maliciously modified called Intel Boot Guard. Their product verifies the integrity of the BIOS by generating a cryptographically trusted boot chain using the Rivest Shamir Adelman (RSA) and Original Equiment Manufacturer (OEM) public keys. Although Intel Boot Guard is suppose to be secure, it has been proven to be bypassed on October 5 due to the proper configurations failing to be set by OEMs.

Attack Surface

The boot guard bypass occurs with a process called BootGuardPei (GUID: B41956E1-7CA2-42DB-9562-168389F0F066), which verifies with Intel Boot Guard. After the verification process is completed, a Hand-Off Block (HOB) value gets stored as a zero, for failure, or a positive value, for success. The problem with the value is that a computer policy does not enforce the failure or success, so the BIOS moves on to running the Driver Execution Environment (DXE) for a integrity check via BootGuardDxe (GUID: 1DB43EC9-DF5F-4CF5-AAF0-0E85DB4E149A). If the integrity check fails, then the HOB returns an error – shutting the system down. An attacker could exploit this vulnerability by deleting the HOB to skip the DXE integrity check. They could also delete the entire section of code that verifies the integrity to bypass the check.

Steps to Bypass Boot Guard

Picture taken from Alex Matrosov

Alex Matrosov, a security researcher who presented at Black Hat 2017, provided a step-by-step method for bypassing Intel’s Boot Guard. Matrosov specifies the following steps:

Picture taken from Alex Matrosov

  1. Modify UEFI firmware update image with rootkit/implant or disable Intel Boot Guard
  2. Recalculate signature on 2048-bit RSA key pair for Initial Boot Block (IBB)
  3. Modify IBB manifest inside UEFI firmware update file
  4. Recalculate signature for IBB manifest with different 2048-bit RSA key pair
  5. Recalculate SHA256 hash of the public key from Root Key Manifest
  6. Modify Boot Guard configuration with active verified boot policy on the Management Engine (ME)
  7. Lock Boot Guard configuration with Field Program Fuses (FPF)

By doing so, an attacker could remotely modify an unsuspecting victim’s BIOS configurations to track and/or steal data without knowing that they have been made.

Vulnerable Models and Versions

Picture taken from Intel

The Intel Boot Guard vulnerability is tracked as CVE-2017-5722 with a high vulnerability rating of 7.5. A security researcher for Embedi, Alexander Ermolov, specifies that multiple firmware based off of the AMI Aptio UEFI BIOS are vulnerable to be bypassed. The OEMs that utilize this type of BIOS are Dell, Gigabyte, ASRock, HP, Acer, Asus, and MSI. These companies own their specific motherboards, which have the vulnerable code that allows malicious users to bypass Intel’s Boot Guard. The product models and versions that are affected are listed on the picture to the left.

Available Patches

Intel has provided patches for multiple vulnerabilities related to their products that are suppose to protect the UEFI and BIOS on October 6. They have since then last updated these patches on October 10. The updates address the Intel Boot Guard Bypass vulnerability, as well as many other BIOS-related vulnerabilities. Other patches address Intel’s CVE-2017-5721: SMM Privilege Elevation, CVE-2017-5701: SPI Write Protection Bypass, and CVE-2017-5700: BIOS Administrator and User password bypass vulnerabilities.


Intel Boot BIOS Security Updates:

Boot Guard Analysis:


Intel Boot Guard Article:

Many Mobile Stock Trading Application Vulnerabilities Discovered

The majority of stock trading has been conducted online for years now through the use of online applications. Customers have been able to transfer funds between banking accounts, track personal buying power, and produce orders to be sold by utilizes the online features. With these convenient online feature, as usual with any feature utilizing the Internet, comes with their associated vulnerabilities. Computer system vulnerabilities are normally a big deal, since those vulnerabilities could be exploited by an attacker to gather sensitive information. Depending on the severity of the vulnerability, sensitive information such as: usernames, passwords, credit card information, and banking information could be revealed to an attacker. In a recent analysis posted on September 26 by IOActive researcher, Alejandro Hernández, found vulnerabilities that would reveal the previously mentioned sensitive information in around 20 of the most popular mobile stock trading applications.

Analysis Background

Picture taken from

According to Hernández, “the latest version of 21 of the most used and well-known mobile trading apps available on the Apple Store and Google Play” were tested for vulnerabilities. He conducted an analysis of these mobile stock trading applications utilizing a stock iPhone 6 version 10.3.3 and an emulated Android version 7.1.1 running as root. He also did not disclose the names of these mobile applications or the names of the companies that own them, since only a few of the associated companies have responded to his email regarding the vulnerabilities and are potentially still vulnerable to being exploited. However, there are 21 online stock trading companies such as: Ally Invest by Ally Financial, Capital One Investing Mobile, Charles Schwab Corporation, DriveWealth, E-Trade, Fidelity Investments, Firstrade Securities, Interactive Brokers, Lightspeed Financial, Merrill Edge by Bank of America, PNC Bank, Robinhood Markets, Scottrade, Suntrust Banks, TD Ameritrade, TradeStation, US Bank, USAA, The Vanguard Group, WellsTrade by Wells Fargo, and Zions Direct.

Discovered Vulnerabilities

Upon concluding his analysis of the mobile stock trading vulnerabilities, Hernández discovered that some applications had credentials stored in plaintext, established an insecure connection, had poor authentication and session management, privacy, data validation, root detection, and hardcoded secrets in their source code.

Plaintext Credentials

Four of the applications stored the username and password to the stock trading account in plaintext. This was within an unencrypted XML file or the log history console. An attacker would need physical access to the victim’s smartphone in order to view this information, so it could be a big problem if someone lost their phone and had auto lock disabled. If an attacker were to gain the login credentials, they could sell stocks, transfer money to a newly added bank account, or delete the bank account after a transfer is complete.

Insecure Communication

Two applications used unencrypted network channels (HTTP) to transmit and receive data sent and received, and around 10 of 20 applications that actually used an encrypted channel (HTTPS) did not verify the Certification Authority (CA) of a Secure Sockets Layer (SSL) certificate via SSL pinning. An attacker could take advantage of this by conducting a Man in the Middle (MitM) attack where they intercept and modify bidding or selling prices of an item or sending false information. These applications had SSL disabled by default, which a customer would not know to turn on for security.

Authentication and Session Management

Hernández also discovered that five applications did not implement the biometric fingerprint-reading authentication. This feature would make a customer’s online stock trading more secure, since their particular fingerprint would be required to authorize any sensitive feature. He also discovered that the applications had a maximum password length of 12 characters. The analysis did not mention if the password length required any special characters or not, but it is a general rule of thumb to be required to create a 16 character password containing at least 1 uppercase, 1 lowercase, 1 special character, and 1 number to be considered a secure password. This is especially relevant for these applications, since it processes transactions directly from the customer’s bank account. The applications also only required a single-factor authentication in order to logon to their account, as opposed to having a secure two-factor authentication method like a text message value and password.

Privacy Mode

One of the 21 applications supported privacy mode, which would prevent a person from shoulder-surfing to gather a victims sensitive information. The remaining 20 applications had information, such as a credit card number appear in plaintext on their screen display. Another privacy flaw Hernández discovered was that an attacker only needs to know the victim’s email address linked to their stock trading account to retrieve a snapshot of their account containing their finances.

Client-side Data Validation

Around ten applications had their web view configured to accept and execute JavaScript code. This could allow an attacker to conduct a Cross-site Scripting (XSS) attack to generate fake login pages to gather victim usernames and passwords to steal money.

Root Detection

Again, Hernández found that the same application that had privacy mode enabled also had root detection enabled. Usually, Android devices normally run as a general user, instead of root. If a user is running an application with administrative privileges (root), then they will be able to authorize any incoming or outgoing request.

Hardcoded Secrets in Code and App Obfuscation

Six Android application installers were also discovered to be easily reverse engineered to view code that a human can read. Hernández found cryptographic keys and passwords to third-party partner by doing so. He also found that ten of the applications had internal hostnames and IP address of development and testing environments where application was created.


IOActive Alejandro Hernández Analysis:

Online Brokerage List:

Stock Trading Application Vulnerability Articles:

Optionsbleed: Heartbleed’s Less Threatening Cousin

Heartbleed is a vulnerability with a feature in OpenSSL, a software application used to establish secure communications over computer networks, known as heartbeat in 2014. This vulnerability affected the Transport Layer Socket (TLS) and Datagram Transport Layer Security (DTLS) in OpenSSL version 1.0.1. This vulnerability allowed attackers to remotely receive confidential information, such as a secret encryption key, from a crafted packed that caused a buffer over-read. Recently, a vulnerability related to Heartbleed was published on September 18 by freelance cybersecurity researcher Hanno Böck. He discovered a vulnerability in Apache HTTP Server, commonly referred to as httpd, which could cause sensitive information to be leaked through memory contents. For this reason, Böck has dubbed this vulnerability Optionsbleed.


Optionsbleed is a vulnerability with Apache HTTP Server that is tracked as CVE-2017-9798. A flaw in Apache’s httpd .htaccess and httpd.conf file, files that configure the OPTIONS setting in a web request, allows a remote attacker to intercept confidential information passing through process memory. This vulnerability is triggered when a “Limit” directive is incorrectly configured in either of the two configuration files. These Limit configurations could be configured to allow or deny web requests for GET, POST, PUT, PATCH, DELETE, HEAD, and TRACE. The problem with the software code for this is that a misspelled word, duplicate valid option, non-existent option is inputted into the configuration file, then the system becomes susceptible to memory leaking.

Affected Systems

The good news about Optionsbleed is there are very few systems that are exposed to sensitive information exposure from the Apache httpd vulnerability. According to the CVE-2017-9798 page, Apache httpd versions 2.2.34 and 2.4.x through 2.4.27 are susceptible to the Optionsbleed vulnerability. Böck conducted an analysis of around 1,000,000 web servers, around 400,000 of which were running Apache, and discovered that there were around 450 web servers that shared OptionBleed characteristics. Another interesting finding Böck discovered is that an attacker could configure their own .htaccess or httpd.conf file to cause a memory leak on a vulnerable web server that is hosting the domain they are using by constantly revisiting the domain to see what kind of sensitive information is fished out. Böck has also released source code on GitHub for end-users to test if an Optionsbleed bug is present in a server running Apache httpd.

Unofficial Patch

At the time of this post, Apache has not officially released a patch, or when they plan on creating one, to address the Optionsbleed vulnerability. However, an unofficial patch is provided on Apaches’ source code servers, which appears to have been created on September 8. Nessus also suggests running the commands “‘yum update httpd24′” and “‘yup update httpd'” on the server to patch the vulnerability as well. If an end-user would prefer to patch this vulnerability themselves or do not trust the unofficial patch, they could also manually search their .htaccess or httpd.conf files for spelling errors, invalid options, or duplicate settings inside of the Limit statement.


Optionsbleed CVE:

Optionsbleed Article:

Böck Analysis:

Sophos Analysis:

GitHub POC:

Open Source Patch:

Nessus Suggestion:

Microsoft .NET and Android Toast Vulnerabilities Patched

Microsoft and Android have recently pushed out updates during this month’s Patch Tuesday for their known vulnerabilities on September 12 and September 5, respectively. Both of these operating system (OS) platforms patched around 80 of these known vulnerabilities. Among the vulnerabilities both OS’ patched were two specific vulnerabilities that could have allowed an unsuspecting victim’s systems to be compromised by an attacker. These vulnerabilities were in Microsoft’s .NET Framework, a software framework used for program language interoperability with several other program languages, and Android’s Toast, a feature in an Android smartphone used to briefly display messages on the screen’s display. By exploiting these vulnerabilities, an attacker could deliver malware to either system that has not been not been updated to the recent patch.   

Microsoft .NET Vulnerability

A zero-day vulnerability addressed in one of Microsoft’s 80 vulnerabilities was in the Microsoft .NET Framework, which is recorded as CVE-2017-8759 and was studied by researchers at FireEye.

The vulnerable .NET versions are (for multiple OSes):

  • Microsoft .NET Framework 2.0 Service Pack 2
  • Microsoft .NET Framework 3.5
  • Microsoft .NET Framework 3.5.1
  • Microsoft .NET Framework 4.5.2
  • Microsoft .NET Framework 4.6
  • Microsoft .NET Framework 4.6.1
  • Microsoft .NET Framework 4.6.2/4.7
  • Microsoft .NET Framework 4.6/4.6.1/4.6.2/4.7
  • Microsoft .NET Framework 4.7

Researchers at FireEye had conducted a forensic investigation on a recent case that had used this vulnerability. They discovered that FinFisher, a so-called lawful interception tool, was installed through remote code execution after a victim opened a Microsoft Word document called “Проект.doc”. This document, translated to English as Project.doc, contained a code to install the components of FINSPY, another naming convention FinFisher goes by. FINSPY then collected and sent the victim’s information to a command and control server to be used for the attackers purposes. FireEye researchers also suggest that a threat group Microsoft calls NEODYMIUM could have been behind the attack, since they have been know for using variants of FinFisher.

Android Toast Vulnerability

One of the vulnerabilities address in Android’s 81 vulnerabilities involved the Toast, which is recorded as CVE-2017-0752.

The vulnerable Android versions are:

  • Android 2.3.3
  • Android 2.3.7
  • Android 4.0.3
  • Android 4.0.4
  • Android 4.1.x
  • Android 4.2.x
  • Android 4.3
  • Android 4.4
  • Android 5.0
  • Android 5.1
  • Android 6.0
  • Android 7.0
  • Android 7.1

Android’s Toast notification feature could be used for an attacker to elevate their privileges to lock the smartphone’s screen, reset the login PIN, erase all device data, and even prevent the victim from uninstalling the malicious application. According to researchers at Palo Alto Networks, an attacker could conduct an overlay attack to have an unsuspecting victim authorize one or multiple administrative features previously mentioned without their knowledge. An attacker could achieve this by creating a malicious application, uploading it to the Google Play store to be downloaded, then infect user’s Android devices. Palo Alto Networks researches have also discovered that Android 8.0 “Oreo” is not at risk for this type of overlay attack, since Oreo effectively handles its permissions checks.


Microsoft .NET vulnerable versions:

Microsoft Zero-Day Patch:

.NET Framework FinFisher:

FireEye Analysis:

Android Patch Tuesday:

Palo Alto Networks analysis: