Google advise users of Windows 7 to give it up and move to Microsoft’s latest operating system if they want to keep systems safe from a zero-day vulnerability exploited in the wild.
To remediate the Chrome vulnerability (CVE-2019-5786), Google released an update for all Chrome platforms on March 1; this update was pushed through Chrome auto-update. Google encourage users to verify that Chrome auto-update has already updated Chrome to 72.0.3626.121 or later.
Bug affects Windows win32k.sys kernel driver on Microsoft windows and leads to privilege escalation on Windows 7.
Windows win32k.sys kernel driver that can be used as a security sandbox escape. The vulnerability is a NULL pointer dereference in win32k!MNGetpItemFromIndexwhen NtUserMNDragOver() system call is called under specific circumstances.
Google strongly believe this vulnerability may only be exploitable on Windows 7 due to recent exploit mitigations added in newer versions of Windows. To date, Google have only observed active exploitation against Windows 7 32-bit systems.
Google reported it to Microsoft. Also in compliance with Google policy, Google publicly disclosing its existence, because it is a serious vulnerability in Windows that Google know was being actively exploited in targeted attacks. The unpatched Windows vulnerability can still be used to elevate privileges or combined with another browser vulnerability to evade security sandboxes. Microsoft have told Google they are working on a fix.
As mitigation advice for this vulnerability users should consider upgrading to Windows 10 if they are still running an older version of Windows, and to apply Windows patches from Microsoft when they become available.
According to Guy Rosen, VP of Production Management at Facebook. On Tuesday afternoon, 25 September Facebook engineering team discovered a security issue affecting almost 50M Facebook user accounts.
A flaw in the “View As” feature allowed attackers to steal Facebook access tokens, which could be used to take over user’s accounts. Access tokens are the equivalent of digital keys that allow users to remain logged into Facebook using stole token.
This attack exploited the complex interaction of multiple issues in our code. It stemmed from a change we made to our video uploading feature in July 2017, which impacted the “View As” feature’, Facebook stated on their website.
First, Facebook fixed the vulnerability and informed law enforcement.
Second, Facebook have reset the access tokens of the almost 50 million accounts Facebook know were affected to protect their security. Facebook also taking the precautionary step of resetting access tokens for another 40 million accounts that have been subject to a “View As” look-up in the last year. As a result, around 90 million people will now have to log back in to Facebook, or any of their apps that use Facebook Login. After they have logged back in, people will get a notification at the top of their News Feed explaining what happened.
Third, Facebook temporarily turning off the “View As” feature while we conduct a thorough security review.
The Internet Corporation for Assigned Names and Numbers ("ICANN") today announced that the plan to change the cryptographic key that helps protect the Domain Name System (DNS) is being postponed.
Changing the key involves generating a new cryptographic key pair and distributing the new public component to the Domain Name System Security Extensions (DNSSEC)-validating resolvers. Based on the estimated number of Internet users who use DNSSEC validating resolvers, an estimated one-in-four global Internet users, or 750 million people, could be affected by the KSK rollover.
The changing or "rolling" of the KSK Key was originally scheduled to occur on 11 October, but it is being delayed because some recently obtained data shows that a significant number of resolvers used by Internet Service Providers (ISPs) and Network Operators are not yet ready for the Key Rollover. The availability of this new data is due to a very recent DNS protocol feature that adds the ability for a resolver to report back to the root servers which keys it has configured.
There may be multiple reasons why operators do not have the new key installed in their systems: some may not have their resolver software properly configured and a recently discovered issue in one widely used resolver program appears to not be automatically updating the key as it should, for reasons that are still being explored.
ICANN is reaching out to its community, including its Security and Stability Advisory Committee, the Regional Internet Registries, Network Operator Groups and others to help explore and resolve the issues.
In the meantime, ICANN believes it prudent to follow its process and to delay the changing of the key rather than run the risk of a significant number of Internet users being adversely affected by the changing of the key. ICANN is committed to continuing its education, communication and engagement with the relevant technical organizations to ensure readiness for the key change.
"The security, stability and resiliency of the domain name system is our core mission. We would rather proceed cautiously and reasonably, than continue with the roll on the announced date of 11 October," said Göran Marby. "It would be irresponsible to proceed with the roll after we have identified these new issues that could adversely affect its success and could adversely affect the ability of a significant number of end users."
A new date for the Key Roll has not yet been determined. ICANN's Office of the Chief Technology Officer says it is tentatively hoping to reschedule the Key Roll for the first quarter of 2018, but that it will be dependent on more fully understanding the new information and mitigating as many potential failures as possible.
ICANN will provide additional information as it becomes available and the new Key Roll date will be announced as appropriate.
"It's our hope that network operators will use this additional time period to be certain that their systems are ready for the Key Roll," said Marby. "Our testing platform (http://go.icann.org/KSKtest) will help operators ensure that their resolvers are properly configured with the new key and we will continue our engagement and communications to these operators."
About DNSSEC
To easily identify resources on the Internet, the underlying numerical addresses for these resources are represented by human readable strings. The conversion of these strings to numbers is done by the distributed hierarchical Domain Name System (DNS). Increased sophistication in computing and networking since its design in 1983 have made this "phone book" vulnerable to attacks. In response to these threats, the international standards organization, IETF, developed DNSSEC to cryptographically ensure DNS content cannot be modified from its source without being detected. Once fully deployed, DNSSEC will stop the attacker's ability to redirect users using the DNS.
According to ICANN millions that will fail after the KSK roll over
LOS ANGELES – 18 September 2018 –The Board of Directors for the Internet Corporation of Assigned Names and Numbers (ICANN) has approved plans for the first-ever changing of the cryptographic key that helps protect the Domain Name System (DNS) - the Internet's address book.
During a 16 September meeting in Belgium, the ICANN Board passed a resolution, directing the organization to proceed with its plans to change or "roll" the key for the DNS root on 11 October 2018. It will mark the first time the key has been changed since it was first put in use in 2010.
"This is an important move and we have an obligation to ensure that it happens in furtherance of ICANN's mission, which is to ensure a secure, stable and resilient DNS" said ICANN Board Chair Cherine Chalaby. "There is no way of completely assuring that every network operator will have their 'resolvers' properly configured, yet if things go as anticipated, we expect the vast majority to have access to the root zone."
Some Internet users might be affected if the network operators or Internet Service Providers (ISPs) have not prepared for the roll. Those operators who have enabled the checking of Domain NameSystem Security Extensions or DNSSEC information (a set of security protocols used to ensure DNSinformation isn't accidentally or maliciously corrupted) are those who need to be certain they are ready for the roll.
"Research shows that there are many thousands of network operators that have enabled DNSSECvalidation, and about a quarter of the Internet's users rely on those operators," said David Conrad, ICANN's Chief Technology Officer. "It is almost certain there will be at least a few operators somewhere across the globe who won't be prepared, but even in the worst case, all they have to do to fix the problem is, turn off DNSSEC validation, install the new key, and reenable DNSSEC and their users will again have full connectivity to the DNS."
The changing of the DNS root key was originally scheduled to happen a year ago, but plans were put on hold after the ICANN organization found and began analyzing some new, last-minute data. That data dealt with the potential readiness of network operators for the key roll.
An analysis ultimately led the organization to believe it could safely proceed with the changing of the key. As a result, the organization, after consultation with the community, developed a new plan that recommends putting the new key into use exactly one year after originally scheduled. In the intervening time, the organization has continued extensive outreach and investigations on how to best mitigate risks associated with the key change.
"This is the first root key change, but it won't be the last," said Matt Larson, Vice President of Research at ICANN and the organization's point person for the key roll. "This is the first time, so naturally we are bending over backwards to make certain that everything goes as smoothly as possible, but as we do more key rollovers in the future, the network operators, ISPs, and others will become more accustomed to the practice."
AMD Patches for Newly Disclosed Processor 13 Critical Vulnerabilities
AMD has finally acknowledged there's a problem with its Platform Security Processor. Earlier this month Israel-based CTS labs found 13 critical vulnerabilities (including RyzenFall, MasterKey, Fallout and Chimera) with AMD's product, which could allow attackers to access sensitive data, install malware and gain complete access to compromised machines (although doing so would require admin access). Today, AMD has published a statement that largely underplays the threat, but claims that patches will be coming soon.
According to CTS-Labs researchers, critical vulnerabilities that affect AMD's Platform Security Processor (PSP) could allow attackers to access sensitive data, install persistent malware inside the chip, and gain full access to the compromised systems.
Although exploiting AMD vulnerabilities require admin access, it could help attackers defeat important security features like Windows Credential Guard, TPMs, and virtualization that are responsible for preventing access to the sensitive data from even an admin or root account.
Official Statement from Mark Papermaster
On March 12, 2018, AMD received a
communication from CTS Labs regarding research into security
vulnerabilities involving some AMD products. Less than 24 hours later,
the research firm went public with its findings. Security and protecting
users’ data is of the utmost importance to us at AMD and we have worked
rapidly to assess this security research and develop mitigation plans
where needed. This is our first public update on this research, and will
cover both our technical assessment of the issues as well as planned
mitigation actions.
The
security issues identified by the third-party researchers are not
related to the AMD “Zen” CPU architecture or the Google Project Zero
exploits made public Jan. 3, 2018. Instead, these issues are associated
with the firmware managing the embedded security control processor in
some of our products (AMD Secure Processor) and the chipset used in some
socket AM4 and socket TR4 desktop platforms supporting AMD processors.
As
described in more detail below, AMD has rapidly completed its
assessment and is in the process of developing and staging the
deployment of mitigations. It’s important to note that all the issues
raised in the research require administrative access to the system, a
type of access that effectively grants the user unrestricted access to
the system and the right to delete, create or modify any of the folders
or files on the computer, as well as change any settings. Any attacker
gaining unauthorized administrative access would have a wide range of
attacks at their disposal well beyond the exploits identified in this
research. Further, all modern operating systems and enterprise-quality
hypervisors today have many effective security controls, such as
Microsoft Windows Credential Guard in the Windows environment, in place
to prevent unauthorized administrative access that would need to be
overcome in order to affect these security issues. A useful
clarification of the difficulties associated with successfully
exploiting these issues can be found in this posting from Trail of Bits, an independent security research firm who were contracted by the third-party researchers to verify their findings.
The
security issues identified can be grouped into three major categories.
The table below describes the categories, the AMD assessment of impact,
and planned actions.
Vulnerability Groups
Problem Description & Method of Exploitation
Potential Impact
Planned AMD Mitigation
MASTERKEY and PSP Privilege Escalation (AMD Secure Processor or “PSP” firmware)
Issue:
Attacker who already has compromised the security of a system updates
flash to corrupt its contents. AMD Secure Processor (PSP) checks do not
detect the corruption.
Method: Attacker requires Administrative access
Attacker can circumvent platform security controls. These changes are persistent following a system reboot.
Firmware patch release through BIOS update. No performance impact is expected.
AMD is working on PSP firmware updates that we plan to release in the coming weeks.
RYZENFALL and FALLOUT
(AMD Secure Processor firmware)
Issue:
Attacker who already has compromised the security of a system writes to
AMD Secure Processor registers to exploit vulnerabilities in the
interface between x86 and AMD Secure Processor (PSP).
Method: Attacker requires Administrative access.
Attacker can circumvent platform security controls but is not persistent across reboots.
Attacker may install difficult to detect malware in SMM (x86).
Firmware patch release through BIOS update. No performance impact is expected.
AMD is working on PSP firmware updates that we plan to release in the coming weeks.
“Promontory” Chipset
CHIMERA
“Promontory” chipset used in many socket AM4 desktop and socket TR4 high-end desktop (HEDT) platforms.
AMD
EPYC server platforms, EPYC and Ryzen Embedded platforms, and AMD Ryzen
Mobile FP5 platforms do not use the “Promontory” chipset.
Issue:
Attacker who already has compromised the security of a system installs a
malicious driver that exposes certain Promontory functions.
Method: Attacker requires Administrative access.
Attacker accesses physical memory through the chipset.
Attacker installs difficult to detect malware in the chipset but is not persistent across reboots.
Mitigating patches released through BIOS update. No performance impact is expected.
AMD is working with the third-party provider that designed and manufactured the “Promontory” chipset on appropriate mitigations.
AMD will provide additional updates on both our analysis of these issues and the related mitigation plans in the coming weeks.
Mark Papermaster, Senior Vice President and Chief Technology Officer
CTS Labs maintains it did the right thing, claiming that they didn't think AMD would be able to fix the problem for "many, many months, or even a year" anyway. CTS Labs' CTO Ilia Luk-Zilberman has also posted a letter on the AMDflaws site in which he explains his gripe with the 90-day response window and why he believes revealing vulnerabilities to everyone at once (consumers and media, as well as the companies in question), puts pressure on the relevant parties to get things fixed.
That certainly appears to be the case with AMD, which says that patch updates can be expected through BIOS updates (without affecting performance) in the coming weeks -- a fair response having been caught so off guard. The issue now, however, would be other security research companies similarly doing away with the 90-day 'rule'. If vulnerabilities were made public the moment they were discovered, they'd never be out of the news, and it would be a real challenge for everyone concerned to know where the risks really were.
Dangerous CredSSP Vulnerability opens door into corporate servers
A critical vulnerability in the Credential Security Support Provider protocol (CredSSP), introduced in Windows Vista and used in all Windows versions since then, can be exploited by MitM attackers to run code remotely on previously uninfected machines and servers in the attacked network
In March Patch Tuesday, Microsoft released a patch for CVE-2018-0886, a vulnerability discovered by Preempt researchers. The vulnerability consists of a logical flaw in Credential Security Support Provider protocol (CredSSP) which is used by RDP (Remote Desktop Protocol) and Windows Remote Management (WinRM) that takes care of securely forwarding credentials to target servers. The vulnerability can be exploited by attackers by employing a man-in-the-middle attack to achieve the ability to run code remotely on previously not infected machines in the attacked network. The vulnerability, in many real-world scenarios where victim network has vulnerable network equipment, could result in an attacker gaining the ability to move laterally in the victim’s network and even infect domain controller with malicious software.
The vulnerability is a logical one and affects all Windows versions to date. In terms of the vastness of this issue, we can note that RDP is the most popular application to perform remote logins. To further highlight this, in Preempt internal research we found that almost all enterprise customers are using RDP, making them vulnerable to this issue.
CredSSP Vulnerability Video
When a client and server authenticate over RDP and WinRM connection
protocols, a man-in-the-middle attacker can execute remote commands to
compromise enterprise networks.
"An attacker which have stolen a session from a user with sufficient
privileges could run different commands with local admin privileges.
This is especially critical in case of domain controllers, where most
Remote Procedure Calls (DCE/RPC) are enabled by default," says Yaron Zinar, lead security researcher for Preempt.
"This could leave enterprises vulnerable to a variety of threats from
attackers including lateral movement and infection on critical servers
or domain controllers."
Since RDP is the most popular application to perform remote logins and
almost all enterprise customers are using RDP, it makes most networks
vulnerable to this security issue.
“The Ryzen chipset, a core system component that AMD outsourced to a Taiwanese chip manufacturer, ASMedia, is currently being shipped with exploitable manufacturer backdoors inside,” reads the whitepaper put out by CTS Labs, the company that discovered the vulnerabilities. “CTS has been researching the security of AMD’s latest Zen processors for the past six months, including EPYC, Ryzen, Ryzen Pro and Ryzen Mobile, and has made concerning discoveries.”
AMD Flaws Overview Video
Before we get into what these vulnerabilities are and how they work, let’s be clear about one thing: There are no patches for these vulnerabilities as of this writing. If you’re compromised, there is not much you can do about it at the moment. That said, if you’re running a Ryzen processor, just be very careful for the next few weeks while we wait for a patch.
Before we get into what these vulnerabilities are and how they work, let’s be clear about one thing: There are no patches for these vulnerabilities as of this writing. If you’re compromised, there is not much you can do about it at the moment. That said, if you’re running a Ryzen processor, just be very careful for the next few weeks while we wait for a patch.
“Firmware vulnerabilities such as Masterkey, Ryzenfall and Fallout take several months to fix. Hardware vulnerabilities such as Chimera cannot be fixed and require a workaround,” CTS Labs reports. “Producing a workaround may be difficult and cause undesired side-effects.”
These vulnerabilities fall into four categories, dubbed Ryzenfall, Fallout, Masterkey, and Chimera. All four lead directly into the secure portion of AMD processors, where sensitive data like passwords and encryption keys are stored, but they achieve their goals in different ways.
“Attackers could use Ryzenfall to bypass Windows Credential Guard, steal network credentials, and then potentially spread through even highly secure Windows corporate network,” CTS Lab reports. “Attackers could use Ryzenfall in conjunction with Masterkey to install persistent malware on the Secure Processor, exposing customers to the risk of covert and long-term industrial espionage.”
The real danger of these vulnerabilities is their pervasive nature. Once someone has wormed their way into the secure processor via Ryzenfall or Masterkey, they are there for good. They can set up camp and spread throughout the network virtually undetected. This is a scary prospect for individuals, but for AMD’s enterprise customers, like Microsoft, it could mean the exposure of very sensitive data to malicious actors on a large scale.
Unlike the Spectre and Meltdown vulnerabilities, which were disclosed to the impacted companies in advance of the information’s public release, these new flaws were not made available to AMD prior to the report’s publication. In response, AMD has released a general statement which digs at CTS Lab’s unorthodox means of disclosure. “This company was previously unknown to AMD,” the statement reads, “and we find it unusual for a security firm to publish its research to the press without providing a reasonable amount of time for the company to investigate and address its findings.”
Samba releases patch to fix Password Reset and DoS Vulnerabilities
Open source server platform Samba has issued patches for two critical vulnerabilities that could be used to launch denial-of-service attacks or allow anyone to change user and administrator passwords.
Samba is a free, open source interoperability suite that extends Windows file and print services to Unix and Linux machines. Businesses that run Unix/Linux and Windows side by side frequently use Samba to link the two operating systems together, making any risk to the security and stability of Samba a serious risk.
The vulnerabilities in question, CVE-2018-1050 and CVE-2018-1057, are both serious risks for anyone using Samba. If your business has a Samba implementation it's highly recommended that you install the applicable security updates.
What the Samba vulnerabilities can do
The first vulnerability, 1050, affects all Samba instances version 4.0.0 and up. More specifically, it only affects version 4.0.0 and up Samba installations that are also running their Remote Procedure Call (RPC) Spool Subsystem Service (spoolss) as an external daemon (RPC spoolss is configured to internal by default).
If the RPC spoolss misses an input sanitization check it can cause the print spooler to crash, effectively killing the ability for anyone using Samba to send files to a printer. Samba says there is no known vulnerability associated with the error, only the denial of service resulting from the crash of the spooler. Samba added that leaving the RPC spoolss set to internal prevents the problem from occurring.
Cisco released 22 security advisories on 07-March-2018, including two alerts
for critical fixes, one of them for a hardcoded password that can give
attackers full control over a vulnerable system.
The hardcoded password issue affects Cisco's Prime Collaboration Provisioning (PCP),
a software application that can be used for the remote installation and
maintenance of other Cisco voice and video products. Cisco PCP is often
installed on Linux servers.
Cisco says that an attacker could exploit this vulnerability (CVE-2018-0141) by connecting to the affected system via Secure Shell (SSH) using the hardcoded password.
Flaw considered critical despite "local" attack vector
The flaw can be exploited only by local attackers, and it also grants
access to a low-privileged user account. In spite of this, Cisco has
classified the issue as "critical."
Although
this vulnerability has a Common Vulnerability Scoring System (CVSS)
Base score of 5.9, which is normally assigned a Security Impact Rating
(SIR) of Medium, there are extenuating circumstances that allow an
attacker to elevate privileges to root. For these reasons, the SIR has
been set to Critical.
The reasons are that an attacker can infect another device on the
same network and use it as a proxy for his SSH connection to the
vulnerable Cisco PCP instance, allowing for remote, over-the-Internet
exploitation.
Furthermore, there is a large number of elevation-of-privilege
exploits affecting the Linux operating system that an attacker can use
and gain root access. Hence, Cisco's decision to classify this flaw as
"critical" even with a CVSS score of 5.9 out of a maximum of 10.
Cisco says there are no temporary mitigations and workarounds that
network admins can deploy to prevent exploitation of older PCP software,
and the company has released patches that PCP owners need to install as
soon as possible.
Second critical flaw: Java deserialization issue in Cisco ACS
The second critical-level vulnerability that Cisco fixed in
yesterday's 22-advisory patch bonanza is a Java deserialization issue
affecting Cisco's Secure Access Control System (ACS), a now-deprecated firewall system.
This is a typical Java deserialization issue. When Cisco ACS tries to
deserialize user-supplied (Java serialized) content, an attacker could
execute code on the device without needing to provide proper
credentials. The malicious code runs as root.
This flaw is tracked as CVE-2018-0147,
and Cisco has released software updates to address the bug. Information
on the other 22 Cisco security advisories can be found on Cisco's security portal.
A critical vulnerability affects hundreds of thousands of email
servers. A fix has been released but this flaw affects more than half of
the Internet's email servers, and patching the issue will take weeks if
not months.
The bug is a vulnerability in Exim, a mail transfer agent (MTA) —software that runs on email servers and which relays emails from senders to recipients.
According to a survey conducted in March 2017, 56% of all of the Internet's email servers run Exim, with over 560,000 available online at the time. Another more recent report puts that number in the millions.
The bug allows for remote code execution
A Taiwanese security researcher named Meh Chang discovered the bug,
which he reported to the Exim crew on February 2. The Exim team released
Exim distribution 4.90.1 on February 10 that fixes the RCE issue.
The bug —tracked as CVE-2018-6789— is categorized as a "pre-auth
remote code execution," meaning an attacker could trick the Exim email
server into running malicious commands before the attacker would need to
authenticate on the server.
The actual bug is a one-byte buffer overflow in the base64 decode function of Exim and affects all Exim versions ever released.
Chang described the bug in a blog post released earlier today, detailing basic steps for exploiting Exim's SMTP daemon.
No PoC or exploit code available
In a security advisory,
the Exim team publicly acknowledged the issue. "Currently we're unsure
about the severity, we *believe*, an exploit is difficult. A mitigation
isn't known," the Exim team said.
Since Exim 4.90.1's release, updated Exim versions have trickled down
to Linux distros used primarily in data centers, but the question
remains about the number of unpatched systems that remain online. Taking
into account that Exim is by far the most popular mail agent,
CVE-2018-6789 opens a large attack surface, and Exim server owners
should look into deploying the Exim 4.90.1 update as soon as possible.
At the time of writing, there is no public exploit code for taking
advantage of vulnerable Exim servers, but this will likely change in the
days following Chang's blog post.
Chang also discovered two other Exim bugs last year, which also led to remote code execution. Those bugs were patched in Exim 4.90.
