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. 



Share:

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 https://www.nsa.gov/ghidra
Share:

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.



Share:

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 (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.
##
ICANN keep informed about KSK Rollover developments go here: https://www.icann.org/resources/pages/ksk-rollover
Share:

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 (https://www.icann.org/resources/board-material/resolutions-2018-09-16-en) 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: http://www.icann.org/kskroll
Subscribe to the rollover discussion mailing list: https://mm.icann.org/listinfo/ksk-rollover
Share:

Popular Posts