Saturday, March 2, 2019

Google suggested Upgrade to Windows 10 to Fix Windows 7 Zero-Day Bug (CVE-2019-5786)

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.
Google suggested Upgrade to Windows 10 to Fix Windows 7 Zero-Day Bug (CVE-2019-5786)

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. 


Thursday, February 28, 2019

NSA Tool GHIDRA - Open Source Software Reverse Engineering Framework

Ghidra is a software reverse engineering (SRE) framework created and maintained by the National Security Agency Research Directorate. This framework includes a suite of full-featured, high-end software analysis tools that enable users to analyze compiled code on a variety of platforms including Windows, macOS, and Linux. 
Capabilities include disassembly, assembly, decompilation, graphing, and scripting, along with hundreds of other features. Ghidra supports a wide variety of process instruction sets and executable formats and can be run in both user-interactive and automated modes. Users may also develop their own Ghidra plug-in components and/or scripts using Java or Python.

In support of NSA's Cybersecurity mission, Ghidra was built to solve scaling and teaming problems on complex software reverse engineering efforts, and to provide a customizable and extensible SRE research platform. NSA has applied Ghidra SRE capabilities to a variety of problems that involve analyzing malicious code and generating deep insights for SRE analysts who seek a better understanding of potential vulnerabilities in networks and systems.
Ghidra is a software reverse engineering (SRE) framework

Friday, September 28, 2018

Facebook security issue affects 50M user accounts

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.

Facebook security issue affects 50M user accounts
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.


Wednesday, September 26, 2018

ICANN KSK Roll over Postponed

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.

ICANN KSK Rollover Postponed
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 ( 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."


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.
ICANN keep informed about KSK Rollover developments go here:

Monday, September 17, 2018

ICANN Board Approval of KSK Roll over

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.

ICANN Board Approval of KSK Roll
"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.
The ICANN Board, during its 16 September meeting, passed a resolution ( approving the plan, and with that, the ICANN org has set in motion its plans to change key at 4PM UTC on 11 October 2018.
"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."
The primary source for information about the rollover is:
Subscribe to the rollover discussion mailing list:

Wednesday, March 21, 2018

Orbitz Travel Booking Company Hacked

Orbitz Travel Booking Company Hacked

Orbitz says a legacy travel booking platform may have been hacked, potentially exposing the personal information of people that made purchases between 2016 Jan 1, and 2017 Dec 22.

The company said Tuesday about 880,000 payment cards were impacted.
Orbitz Travel Booking Company Hacked
Orbitz said data that was likely exposed includes name, payment card information, date of birth, phone number, email address, physical and/or billing address and gender. The company said evidence suggests an attacker may have accessed information stored on this consumer and business partner platform between 2017 Oct 1 and 2017 Dec 22.

The current website was not involved in the incident. It’s now owned by Expedia Inc. of Belleview, Washington.

Orbitz is offering those impacted a year of free credit monitoring and identity protection service in countries where available.

AMD Patches For Newly Disclosed Processor 13 Critical Vulnerabilities

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.
AMD Patches For Newly Disclosed Processor 13 Critical Vulnerabilities

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.

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 GroupsProblem Description & Method of ExploitationPotential ImpactPlanned AMD Mitigation
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.


(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 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.



Popular Posts