Google has disclosed a Windows zero-day vulnerability after Microsoft failed to release a patch within the 7-day deadline the search giant gives vendors when it finds a flaw that is actively exploited by malicious actors.

Google researchers discovered recently that the Windows kernel is affected by a local privilege escalation vulnerability that allows attackers to escape the sandbox.

“[The vulnerability] can be triggered via the win32k.sys system call NtSetWindowLongPtr() for the index GWLP_ID on a window handle with GWL_STYLE set to WS_CHILD. Chrome's sandbox blocks win32k.sys system calls using the Win32k lockdown mitigation on Windows 10, which prevents exploitation of this sandbox escape vulnerability,” Google said in a blog post on Monday.

Google typically gives companies 90 days to patch vulnerabilities found by its researchers, but vendors are advised to develop fixes or at least provide workarounds within 60 days if the flaw is critical. However, if a security hole is being exploited in the wild, vendors only get 7 days to take action.

On October 21, Google informed Microsoft and Adobe of Windows and Flash Player vulnerabilities that had been actively exploited. Adobe managed to patch Flash Player a few days later, but Microsoft still hasn’t released a fix or an advisory.

“We believe in coordinated vulnerability disclosure, and today’s disclosure by Google could put customers at potential risk. Windows is the only platform with a customer commitment to investigate reported security issues and proactively update impacted devices as soon as possible. We recommend customers use Windows 10 and the Microsoft Edge browser for the best protection,” a Microsoft spokesperson said in an emailed statement.

In the case of Adobe, Google discovered that malicious actors had been exploiting a use-after-free vulnerability (CVE-2016-7855) in limited, targeted attacks aimed at users running Windows 7, 8.1 and 10.

The patches released by Microsoft in October addressed a total of four vulnerabilities exploited in the wild, including weaknesses leveraged by advanced persistent threat (APT) actors in cyber espionage operations and by profit-driven cybercriminals in malvertising attacks.

This is not the first time Google has disclosed Windows vulnerabilities before Microsoft could release a patch. In late 2014 and early 2015, Google Project Zero published the details of several flaws after the 90-day deadline expired. At the time, the company made some changes to its disclosure policy after being criticized by some members of the industry.

*Updated with statement from Microsoft

Related: Zero-Day Patched by Microsoft Used for Malvertising Since 2014

Previous Columns by Eduard Kovacs:

Tags:

A Dutchman accused of launching an unprecedented cyberattack that reportedly "almost broke the internet" is to go on trial Tuesday on charges of masterminding the 2013 incident that slowed down web traffic world-wide.

But Sven Olaf Kamphuis, 39, denounced the case against him, and told the AD daily newspaper in a Skype interview that he would not appear at the court in the southern Dutch city of Dordrecht. He will be represented by his lawyers.

He is accused of being behind a massive so-called distributed denial of service (DDoS) attack in March 2013 on Geneva and London-based volunteer group Spamhaus, court spokeswoman Lily Derksen told AFP.

Spamhaus publishes spam blacklists used by networks to filter out unwanted email. And it blamed Dutch web-hosting service Cyberbunker for the attack, one of the largest in the history of the internet at the time.

At the time, Kamphuis was said to be a spokesman for Cyberbunker.

"The cyberattack and its subsequent domino effect was so big that the world came within a hair's breadth of being without the internet for a week," the popular daily tabloid Algemeen Dagblad said.

Arrested in Spain, Kamphuis was eventually extradited to The Netherlands, where he was remanded for two months in May 2013.

Kamphuis -- who refers to himself as the "minister of telecommunications of the Cyberbunker republic" -- told the AD newspaper that the charges were "absurd."

He added he is counter-suing the Dutch state for 102 million euros ($111 million) in damages.

Kamphuis' lawyer Marcel van Gessel told the paper his client was "out of the country" and it is believed he was either living in Barcelona or in Berlin.

So-called distributed DDoS attacks essentially bombard sites with traffic from various sources in order to disrupt or seize servers.

The attack was described as the most powerful ever seen and slowed web traffic. The attacks began, according to Spamhaus, after it placed Cyberbunker, a web hosting firm that "offers anonymous hosting of anything except child porn and anything related to terrorism", on its blacklist.

Cyberbunker said it had been unfairly labelled as a haven for cybercrime and spam.

Experts said the attacks flooded Spamhaus servers with 300 billion bits per second (300 gigabytes) of data. Prior DDoS attacks had been measured at 50 gigabytes per second.

© AFP 2016

Tags:

The US government and private sector should strike back against hackers to counter cyberattacks aimed at stealing data and disrupting important computer networks, a policy report said Monday.

A panel of experts assembled by the George Washington University Center for Cyber and Homeland Security said policies should be eased to allow "active defense" measures that deter hackers -- differentiating that from the idea of "hacking back" to disable systems used by attackers.

The panel envisioned measures such as taking down "botnets" that disrupt cyberspace, freeing data from "ransomware" hackers and "rescue missions" to recover stolen data.

"The time for action on the issue of active defense is long overdue, and the private sector will continue to be exposed to theft, exfiltration of data, and other attacks in the absence of a robust deterrent," the report said.

"When private sector companies have a capability to engage in active defense measures, they are building such a deterrent, which will reduce risks to these companies, protect the privacy and integrity of their data, and decrease the risks of economic and societal harm from large-scale cyberattacks."

The report follows a wave of high-profile attacks against US companies and government databases, and after the Obama administration accused Russia of using cyberattacks to attempt to disrupt the November presidential election.

US policymakers are moving too slowly in dealing with a "dynamic" threat from cyberspace, former national intelligence director and task force co-chair Dennis Blair said.

"We are shooting so far behind the rabbit that we will only hit it if the rabbit makes another lap and comes back to where it was," he told a conference presenting the report.

However, the panel did not recommend hacking back "because we don't want the cure to be worse than the disease," project co-director Frank Cilluffo said.

But "there are certain steps companies can take" to repel and deter cyberattacks, he added, advocating the establishment of a legal framework for them.

Although the scope of the problem is understood, the solutions remain controversial.

Some of the recommendations go too far by inviting companies to gain unauthorized access to outside computer networks, task force co-chair Nuala O'Connor, president of the Center for Democracy & Technology, said in a dissent.

"I believe these types of measures should remain unlawful," she wrote, adding that it remains difficult to be sure of cyberattacks' sources.

"The risks of collateral damage to innocent internet users, to data security, and to national security that can result from overly aggressive defensive efforts needs to be better accounted for."

© AFP 2016

Tags:

PCI DSS version 3.1 will be retired on October 31, 2016, with version 3.2 being the only valid version beginning the 1st of November. From that date, any new validation of PCI compliance will have to be against version 3.2. The new requirements will, however, be considered 'best practices' until Feb. 1, 2018 when they will be mandatory.

One of the most important requirements is completion of the migration from SSL and early TLS to the more secure later versions of TLS. Alexander Norell, EMEA director at Trustwave's Global Compliance and Risk Services, told SecurityWeek that this is designed to mitigate against increasing man-in-the-middle attacks against e-commerce. If an attacker gets access to a merchant, then POODLE  or BEAST can gain access to the session.

Norell thinks this migration will be a particular problem for the small merchant that contracts out the entire payment process. Such companies will be accustomed to thinking the service provider is responsible for security; but while you can contract out the process, you cannot contract out the responsibility. Small merchants will still need to take reasonable steps to ensure that their providers are complying with the new regulations; even if their current contracts don't allow for provider audits.

The SSL migration was originally introduced in PCI 3.1. However, large service providers with thousands of international customers with different SSL and TLS configurations had problems meeting the deadline. The PCI Security Standards Council (PCI SSC), the body that defines PCI DSS, took a decision to extend the deadline by re-introducing the requirement into version 3.2 -- effectively pushing the deadline back until February 2018. The PCI Security Standards Council (PCI SSC, which defines the standard) stresses, however, that this should not be seen as an invitation to delay action: SSL and early TLS are vulnerable and continuing to rely on them invites a breach.

SSL migration is not, however, the only new requirement -- and since some of these (particularly around multi-factor authentication and penetration testing) will require planning and budgetary approval, it is important to get the ball rolling as soon as possible. Jeremy King, International Director at PCI SSC, suggests that moving to a multi-factor administrator access (MFA) requirement could be time-consuming.

"From Feb 2018," said King, "administrators must have MFA whenever they access the card data environment. That is quite a significant change. So companies need to read 3.2, understand the impacts, and where necessary get the budgets in place." One difficulty for large organizations will be locating all administrator accounts and ensuring that all have the new MFA credentials. 

Zhang Wanqiao, a Chinese researcher from Qihoo 360, demonstrated at the recent Ruxcon Security Conference that any dedicated attacker could intercept calls and text on any 4G LTE network anywhere in the world. It's not a new vulnerability, but the exploitation is easier than previously thought. "The phone situation gets challenging with the increase in mobile commerce," said King. "It's difficult to say that a transaction conducted on a mobile phone that receives a soft token to the same phone is really multi-factor because it's all on the same device. If somebody steals or highjacks that phone, they're getting everything."

This implies that MFA admin access must not allow the second factor to be delivered to the same device -- which is the position taken by NIST in its recent MFA proposals. This does not mean that phone-based SMS authentication is completely ruled out. "If you conduct the transaction from a laptop, and you send the token to a separate phone or other device, then that's a genuine second factor," explained King.

PCI DSS 3.2 is not the only major standard coming into force in early 2018 -- GDPR will also be required by spring 2018. Both are designed to improve security -- one for card and cardholder details, and the other for European personally identifiable information. There is clearly an overlap; but there is a big difference in the way the two standards are phrased. GDPR describes its requirements by what must be achieved; PCI DSS explains how achievement is expected. There is much more hands-on guidance in PCI DSS.

"People come to me and say, 'How do I achieve GDPR compliance?'" commented King. His reply is to say, "Start with PCI DSS." Any company that fully and successfully implements PCI DSS 3.2 is likely to be fully GDPR compliant -- it's a case of buy one and get one free.

Kevin Townsend is a Senior Contributor at SecurityWeek. He has been writing about high tech issues since before the birth of Microsoft. For the last 15 years he has specialized in information security; and has had many thousands of articles published in dozens of different magazines – from The Times and the Financial Times to current and long-gone computer magazines.

Previous Columns by Kevin Townsend:

Tags:

The group calling itself Shadow Brokers has leaked more files, including a list of servers allegedly used by the NSA-linked Equation Group in its attacks.

The Shadow Brokers emerged in mid-August when it leaked 300 Mb of firewall exploits and implants allegedly taken from Equation Group servers. While many of the exploits were old, they still helped firewall vendors discover some previously unknown vulnerabilities.

The threat actor initially attempted to auction the other files it possessed, but after that plan failed, it announced that everything would be made public once it raised 10,000 bitcoins. With only just over 2 bitcoins raised so far, it’s unlikely that this plan will work.

However, Shadow Group announced on Monday the release of a new batch of files. They suggested that the IPs mentioned in these files correspond to machines used by the Equation Group to breach networks.

The latest leak has been analyzed by several security experts. Researcher Mustafa Al-Bassam said the files appear to contain a list of compromised servers used by the Equation Group as exploit staging servers. However, the expert pointed out that since the targets were compromised between 2000 and 2010, the affected machines have most likely been cleaned up by now.

However, an analysis of the dump conducted by Hacker House shows that some of the affected hosts are still active and running the previously undisclosed tools mentioned in the latest leak.

“These hosts may still contain forensic artifacts of the Equation Group APT group and should be subject to incident response handling procedures,” researchers said.

The list of tools referenced in the files includes DEWDROP, INCISION, JACKLADDER, ORANGUTAN, PATCHICILLIN, RETICULUM, SIDETRACK and STOICSURGEON. Other tools referenced in the leak are Intonation and Pitchimpair – Shadow Brokers suggested that the latter is some sort of redirector tool. It’s worth noting that the names of these tools seem to follow the same naming convention as the ones from the NSA’s famous ANT catalog.

Hacker House has identified 352 IP addresses and 306 domain names, including 32 .edu and 9 .gov domains, distributed across 49 countries, mostly in the Asia Pacific region. The top 10 affected countries are China, Japan, Korea, Spain, Germany, India, Taiwan, Mexico, Italy and Russia.

According to Hacker House, there is indication that the Equation Group may have been using a Sendmail exploit.

In its latest statement, Shadow Brokers also discusses the upcoming elections in the United States. The group has urged people to disrupt the elections, either through hacking or physical actions, such as protests and smashing voting equipment.

The hackers insist that their main goal is to make money from the Equation Group files, but many experts pointed out that the files are not as valuable as the hackers believe them to be.

It’s still unclear who is behind the Shadow Brokers. Theories include the Russian government, an NSA insider and opportunistic hackers who found the data on a server. A linguistic analysis conducted by Taia Global suggests that whoever is behind Shadow Brokers is a native English speaker trying to appear non-native. The latest statement published by the group seems to support this theory.

Related: NSA Contractor Arrested for Theft of Classified Material

Related: Industry Reactions to Shadow Brokers Leak

Previous Columns by Eduard Kovacs:

Tags:

What Does an Organization Need to do to Get Shadow IT Under Control?

Shadow IT and sanctioned cloud apps are gaining ground in the enterprise. At last count, employees at enterprise-class organizations were using 841 different apps on average, according to Blue Coat Elastica Cloud Threat Labs. It would seem that these days the only thing growing as quickly as the proliferation of cloud apps are the security and compliance issues accompanying them. For companies that adopt cloud apps faster than they apply effective security there are dangerous implications, but risks associated with use of cloud apps can be mitigated with technologies available today through CASB gateways, CASB cloud app API integration, and secure web gateways.

As we’ve seen, cloud apps are already an essential part of business in our digital and connected age. The adoption rates of SaaS are fast and only accelerating, and it’s viewed by many in the executive suite as the #1 disruptive technology currently at play in the enterprise. The benefits of cloud apps are many. Compared to the older client-server model of actual software licenses and installations, cloud apps are very cost effective, boast far easier remote access, they spin up and adapt very quickly, and they can improve both productivity and collaboration.

As many of us in the security industry already know, the presence of Shadow IT can wreak havoc on compliance. When data is going through third-party SaaS applications, for instance, it’s important to understand what security risks those applications pose and whether those risks fall within the guidelines accepted by the relevant compliance standards. These, in many cases, include SOX, PCI-DSS, HIPAA and COBIT, among others.

Compliance is but one example where Shadow IT can cause problems. We’re now in an environment where there’s a great deal of cloud app adoption and often times with executive sponsorship. But the problem for IT security and risk professionals is they often have no way of actually knowing which cloud apps are running on their infrastructure and which employees are using them. Security teams many times just don’t have the tools to monitor and control any of these cloud apps — and that’s a big and at times very costly problem.

So what does an organization need to do to wrangle Shadow IT and get it under control?

Here are four steps you need to take to solve this problem.

1. Visibility. As I’ve stated above, you need to know which cloud apps are being used. You will need an audit solution such as the Blue Coat Elastica Audit. By taking logs from proxies, firewalls and logs from other appliances on the network, an audit solution will generate a report that will detail all the different cloud apps running on your infrastructure and the associated users. A good audit solution will also provide you with the characteristics around those apps. Once this is in place, you’ve gone from having no information whatsoever to to knowing exactly which cloud apps are being used in your organization — it’s now no longer Shadow IT. These characteristics are very important to know: what are the risks associated with these apps and how do you evaluate each of these apps based on a myriad of different attributes. Ultimately, you want to be able to assign an app some sort of rating: the higher the number, for instance, the less risk it carries and the more business-ready it is. You also want a solution that allows you to set varying levels of characteristics and attributes, such as multifactor authentication, compliance and encryption requirements, among others.

2. Analysis. Here you really need to dive in and explore exactly what are the risks associated with these apps you’ve identified in step 1 above. What precisely makes these apps risky, do they meet varying compliance requirements, have you solved for issues of data sovereignty? A quality audit solution will be able to provide an extremely detailed report with all the needed information to undertake the next step.

3. Decision making. OK, you’ve gained visibility, analyzed, and now you’re ready to decide which apps can remain in your environment and which must be shut down. You now have the information to decide which apps you’ll monitor, which will be completely green-lighted and which must be banished to protect your organization. Ideally, you’ll also want an audit solution that allows you to perform a comparative analysis, side by side, of alternative apps to find the one(s) with a lower risk profile. An added bonus is that the decision-making step also can enable cost cutting by consolidating multiple accounts used by different departments within the same organization or by eliminating access to non-sanctioned apps.

4. Enforce controls. This is the step where you really dial things in and control cloud app activities as they’re ongoing. You’ll want to set your policies based on your audit solution feed and, also, to be able to set those cloud app policies with your proxy. To accomplish this, you will also need the detailed characteristics of those apps — business readiness ratings, risk attributes and the like — fed through the network to your proxy.

Of course, it’d be great if this were all you needed to do. But there’s one final step that I didn’t include above because it’s something that will always be ongoing: continuous monitoring. This whole process doesn’t come to an end once you’ve completed the above four steps. You’ll need to monitor because cloud apps change all the time, are updated, cloud app risk ratings will increase or decrease, and new functions of cloud apps will need to be properly vetted, among a host of other always-changing variables.

The steps I’ve outlined above are a great way to get your arms around the big issues of Shadow IT today. The cloud is here to stay, and so long as employees use cloud apps from within an organization’s firewall, we’ll always have to wrangle with Shadow IT, Shadow Data and the attendant problems and risks. Because of this, you’ll need an integrated visibility and control solution that provides the integrated CASB and proxy capabilities listed above.

Aditya K. Sood (Ph.D) is, director of Security and Elastica Cloud Threat Labs at Blue Coat Elastica, now part of Symantec. Dr. Sood has research interests in malware automation and analysis, application security, secure software design and cybercrime. He has worked on a number of projects pertaining to penetration testing specializing in product/appliance security, networks, mobile and web applications while serving Fortune 500 clients for IOActive, KPMG and others. He is also a founder of SecNiche Security Labs, an independent web portal for sharing research with security community. Dr. Sood obtained his Ph.D from Michigan State University in Computer Sciences.

Previous Columns by Aditya Sood:

Tags: