(In)Security Management Engine

   The out of band management system bundled on almost all Intel processors has become a hot target for attackers in recent years. This is because it runs alongside the main processor and has virtually unrestricted access to all the hardware in the machine. As long as the machine has power the management engine is sitting there silently waiting for commands from a system administrator with access to it. While this feature can be a huge help for administrators managing a large number of machines it also presents an extremely attractive attack point.

    Intel provides a number of different subsystems under the Converged Security and Management Engine (CSME). The management engine is the specific firmware for mainstream chips, they also provide Server Platform Services (SPS) for server hardware and the Trusted Execution Engine (TXE) for tablets and other low power devices. Security researchers have been skeptical of the CSME for years due to it being closed source, having full access to the hardware, and its inability to be disabled. Several vulnerabilities have been found in the system by various researchers in the past. It’s time to make sure your systems are up to date as Intel just released a bug advisory with 77 found vulnerabilities, including one listed as critical.
    The most critical vulnerability found (CVE-2019-0169) is a heap overflow bug that could allow an unauthenticated attacker to take over a target system or cause a denial of service. Other high security bugs were found as well including cross site scripting, insufficient access control, and privilege escalation. For most of the attacks the only requirement is that the target machine is on the same network as the attacker. While many of the vulnerabilities allow an already privileged user to escalate their privileges, some of them require no prior authorization. By chaining these types of vulnerabilities together it would be possible for someone to go from having no access to having full privileges on the machine.
    Most of the vulnerabilities were found by Intel itself as part of an internal audit designed to harden the CSME system. 10 of the vulnerabilities came from independent researchers who reported the bugs to Intel. As always, it is important to make sure your systems are up to date, especially if public facing or used on untrusted networks. The required patches are typically bundled in your operating systems update mechanism such as processor micro code updates. Depending on your specific hardware and software setup you may have to acquire and run the updates manually.


 • https://threatpost.ccom/intel-critical-info-disclosure-bug-securityengine/150124/


Vulnerability in Amazon’s Ring Video Doorbell

    Researchers at Bitdefender have found a vulnerability in Amazon’s Ring Video Doorbell which allows an attacker with proximity to the device to intercept the Wi-Fi credentials of the network it operates on, which could lead to further attacks to devices on the network. The Ring Doorbell is an IoT device that allows a person to remotely view and communicate to people on their property. The exploit revolves around the setup procedure and the lack of security in place during that setup. The researchers say that while setting up the device, the doorbell will broadcast an unprotected wireless signal which is meant to facilitate the communication between the app and the device. Besides this, the communication between the app and the doorbell is done insecurely through HTTP. This means that when the app prompts the user to enter their home Wi-Fi credentials, an eavesdropper can see the password in plaintext. This could then lead to exploitation of the network and attacks against the devices on it.

    While the doorbell is only vulnerable when performing the initial setup, the researchers say that there is a way to trick the user into going through the setup again. They discovered that sending de-authentication messages to the device will make the user think that the device is not properly working, leading them to reconfigure it. A de-authentication attack is a type of denial of service attack where an attacker continuously sends de-authentication frames to one or more devices, preventing them from connecting to the network. While sending the de-authentication messages, the doorbell will disconnect itself from the Wi-Fi network and make it unable to reconnect. The last resort to resolve the connection issue is to reconfigure the device by going through the setup process again, leading to an eavesdropper gathering the credentials.

    Ring has since patched this vulnerability with the release of its newest software update and urges its users to perform an update on their device. However, users that have not yet updated should be aware of this method to force a reconfiguration. If you suddenly find that the device is unable to connect to Wi-Fi you may be the victim of this attack. The exploitation of this vulnerability, while relatively easy, does require the attacker to be within some proximity to the network. This is not the first time that Ring has exposed users’ Wi-Fi passwords to attackers. In 2016, researchers found that by pushing a button on the device to activate access point mode, an attacker could use a mobile device to navigate to a URL that exposed the network settings. While IoT devices can provide great benefits to consumers, they must contain proper security controls.




Amazon Alexa and Google Home are listening

    Amazon Alexa and Google Home are listening. It’s likely you are aware of the security and privacy concerns as well as their mitigations. It’s the price we pay for the technology we want. Unfortunately, there is another attack vector recently exposed by researchers at Germany’s Security Research Labs (SRL). The most interesting part of this research is that it is an absolute “confirmed proofof-concept”. The researchers developed four Alexa “skills” and 4 more Google Home “actions”, submitted the malicious apps where they all passed Amazon and Google security vetting processes, and made it into the respective markets. SRL developed two types of malicious applications: a set for eavesdropping, and a set for phishing. The eavesdropping apps responded to the wake phrase and provided the requested information while the phishing apps responded with an error message. Both methods created the illusion of stopped functions while proceeding silently with their attack. The eavesdropping attacks used methods involving pauses, delays, and exploiting flaws in text-to-speech engines speaking unspeakable phrases that produced no auditable output. This gave the impression that the application finished when it was still listening, recording, and sending it back to the application developer. In the case of the phishing apps, the error message created the impression that the application had finished unsuccessfully. Similar tricks to keep the application running were used followed by the application mimicking the device voice claiming there is an update available and requesting that the user say their account password. Neither Amazon Alexa nor Google Home do this, but naive users might respond. These seem like they may not be too effective- a user may not say anything of utility or anything at all to the eavesdropper and they should know to ignore the requests of a phishing attempt.

    But these attacks highlight key issues:

• What vetting process is Amazon or Google using?

• What other exploitable flaws exist in their vetting methods?

• Why would Amazon or Google allow a functionality change after review?

    Google Play has an unfortunate history of hosting a variety of malicious apps and eavesdropping concerns have been previously reported by Checkmarx and MWR Labs for Alexa skills. SRL did report the results of its research to Amazon and Google through their responsible disclosure process. Both companies removed the apps and said they are changing their approval processes to prevent skills and actions from having similar capabilities in the future. But SRL’s success raises serious concerns and it’s worth noting these key issues are not only applicable to listening smart home devices but can be considered for all applications available on any platform. I’m not ready to give them up just yet, but Dan Goodin of ARS Technica sums it up this way: “SRL’s research only adds to my belief that these devices shouldn’t be trusted by most people.”




Adobe Data Leak

    Multinational software company Adobe has suffered a data leak that exposed the account information of an estimated 7.5 million customers, according to security researcher Bob Diachenko. Those affected were subscribers to Adobe’s Creative Cloud service which provides users with access to its line of software applications which includes Photoshop, Illustrator, and After Effects, among others. This leak is the result of an unsecured and poorly implemented Elasticsearch database.

    The researchers discovered the database on October 19th and notified Adobe the same day. Exposed information includes email addresses, owned products, account creation date, subscription status, account ID, country, last login date, and if the user is an Adobe employee. The database did not include any financial information or passwords. It is also unknown whether this database had been stumbled upon before researchers found and disclosed it to Adobe. Adobe released a blog post stating that” last week, Adobe became aware of a vulnerability related to work on one of our prototype environments. We promptly shut down the misconfigured environment, addressing the vulnerability.” Adobe also confirmed that the data did not include any passwords or financial information.

    This is not the first time Adobe has been careless about how user information is stored. In 2013, Adobe suffered a major data breach that affected at least 38 million users but could have affected up to 150 million. This 2013 breach also resulted in the loss of password data as well as stolen source code for several Adobe products. Analysis of this breach found that Adobe was improperly storing passwords, allowing for many of the most common passwords to be guessed. At the time, the 2013 breach was considered one of the worst data breaches to have occurred. 

    While the leaked data may seem unalarming, it may still be a cause for concern. Using the leaked data, a malicious actor could create a very targeted phishing campaign. Typically, phishing emails are sent to a wide range of individuals, and because of this tend to not include information relevant to the recipient. However, using this data an individual could use details such as first and last name, account number, subscription status, and last login date to create a very convincing phishing email. While, as previously stated, it is unknown as to whether this information was found by anyone else, users should still be aware of possible phishing emails containing Adobe account information. 




Computer Baselines

    Security, for many, seems hard to do right.   I know that we all think about firewalls, patch
management, antivirus and physical security.  
But I like to cover an area that does not get focused on by most

     Baseline and inventory of computers on a network are often overlooked.  I ask all the time, “Do you know what the
computers are in your network?  What are
the services that are running?  What
ports are open?  Who uses the
services?  Who are the users?”

    For the most part, I hear “Uh, no. We don’t know.”   If you do not know what’s running on your
systems, how will you know what changed if someone breaks into your network?  How will you know?  I believe that you need to create a master
file (portfolio) that lists what the computers/servers are doing; what tasks/services
are being run; what ports are open; who is the owner of that application; who
are the users; what are the data backup requirements, 1 a day, once and hour ?;
and finally, who maintains master file (portfolio)?
    If you have this as minimum documentation you can then do a
risk assessment and identify all the systems and prioritize what needs to be
monitored and controlled.