Intel Patches Serious Logic Bug That Lurked Since 2010
It’s 2017, and considering Intel’s most recent advisory, coordinated vulnerability patching, along with synchronized and accurate information disclosure across enterprise environments is still a hot mess.
In what can only be described as one of the most confusing and controversial vulnerabilities in recent memory, Intel has addressed a vulnerability that affects Active Management Technology (AMT), Intel Small Business Technology (SBT), and Intel Standard Manageability (ISM) protocols.
The confusion arises in the severity, the type of vulnerability, and what devices are in scope for this vulnerability. The vulnerability, CVE-2017-5689, was initially described as a remote code execution vulnerability affecting devices since 2008, allowing attackers to compromise machines without authentication.
However, Intel and other researchers have declared that the vulnerability was, in fact, a logic flaw and an escalation of privileges. Both parties even disagreed over when the flaw was introduced, some saying it has been lurking since 2008, while others say it was introduced only in AMT version 6.0, which was deployed in late 2010 and early 2011.
After disseminating all the results and parsing the multitudes of advisories and technical summaries, even experts are still scratching their heads as to what, exactly, is exploitable, and how an attacker could cause it to trigger the exploitable condition.
In summary, the vulnerability appears related to AMT and ISM network management traffic, which is silently redirected to Intel hardware and Intel ME/Local Management Service (LMS) via intercepting traffic on ports 16992, 16993, 16994, 16995, 623, and 664 (by default).
It is important to understand that the underlying operating systems (OS) of these machines with AMT enabled will never see any network traffic to these ports. This also means that the OSs defenses against such attacks, such as host-based firewalls, IPS, memory protections (ASLR, CFG, DEP, etc) will never be applied to the attack vector; thus allowing attackers to exploit the Intel chipset directly.
Guidance from both Intel and several researchers suggests that even though AMT has authentication features, they can be bypassed or the attack can be triggered prior to their enforcement. In addition, the attack appears to be related to ISO images being loaded.
If all of this is true, the vulnerability could allow an attacker to bypass a logic check and mount a virtual LiveCD. This can be abused by booting into an attacker-controlled OS that would circumvent security settings, manipulate the original OS or its files, and compromise the device.
Additionally, a second vulnerability that allows logged in administrator users to modify settings to gain privileges and abuse AMT features is also addressed in the update. This issue is most likely to be abused by individuals looking to install a novel persistence mechanism on affected devices. Administrators should use the supplied documents to disable AMT or apply the patch where available.
Hacking Gmail Like Its 1999
In what seems to be yet another blast from the mid-2000s, a web-based worm has propagated using Google services in a highly sophisticated OAuth based attack. The malware exploit’s features within Google’s OAuth protocol trick users into believing a contact of theirs has shared a Google Document with them. Upon opening the malicious email attachment, the malware redirects the user to an OAuth authentication and permission page to allow the attacker’s malicious app, “Google Docs” to gain permissions to access their account.
This isn’t the first time baddies have squatted on Google trademarks. Unlike traditional phishing attacks, this clever campaign relies on Google’s OAuth infrastructure, rather than the attacker’s Google-hosted application, to gain access or phish a victim’s credentials. By abusing Google’s features, even the most vigilant netizens can fall victim to the seemingly harmless request.
Victims who successfully allowed “Google Docs” to gain access to their accounts inadvertently allowed the malicious authors of the worm to gain access to not only their contact list, but also their OAuth token - plus their account information, including login permissions. The worm then accesses their contacts and sends them a copy of itself, a throwback to the era of Melissa and LoveLetter malware of the early 2000s.
Victims of the attack are advised to check their Google account permissions, using https://myaccount.google.com/permissions?pli=1 to list their current installed app permissions associated with their account.
Note that the presence of the application “Google Docs” is an indicator of a compromise: “Google Drive” is the legit application name. Victims should remove the application from their permissions, change their password, and enable two-factor authentication (2FA) if it has not been enabled prior to this event. Fortunately, Google’s OAuth policy will automatically reset all of an account’s OAuth tokens upon password reset.
Interestingly enough, OAuth exploitation was covered in depth by Greg Carson (@g_kay_c) in February of this year. The attack uses very similar principles and methods mentioned by Carson, and it is likely an early precursor to where this attack originated.
OAuth is no stranger to exploitation. Many previous exploits involved data exfiltration methods or complete bypasses of authentication. Since it is very likely in the upcoming weeks that researchers and attackers will be focusing on OAuth attacks, administrators are advised to stay vigilant and review how each OAuth policy system handles tokens, and plan what to do if a user’s token is suspected to have been hijacked or compromised.
