Information Technology

Image: Joshua Hoehne
The operators of the REvil ransomware strain have “acquired” the source code of the KPOT trojan in an auction held on a hacker forum last month.

The sale took place after the KPOT malware author decided to auction off the code, desiring to move off to other projects.
The sale was organized as a public auction on a private underground hacking forum for Russian-speaking cyber-criminals, security researcher Pancak3 told ZDNet in an interview last month.
The only bidder was UNKN, a well-known member of the REvil (Sodinokibi) ransomware gang, Pancak3 said.
UNKN paid the initial asking price of $6,500, while other forum members declined to participate, citing the steep asking price.
The REvil operator received the source code of KPOT 2.0, the latest version of the KPOT malware.
First spotted in 2018, KPOT is a classic “information stealer” that can extract and steal passwords from various apps on infected computers. This includes web browsers, instant messengers, email clients, VPNs, RDP services, FTP apps, cryptocurrency wallets, and gaming software, according to a 2019 Proofpoint report.

Pancak3, who first spotted the KPOT auction in mid-October, told ZDNet that he believes the REvil gang bought KPOT to “further develop it” and add it to its considerable arsenal of hacking tools the gang uses during its targeted intrusions inside corporate networks.

Although many other forum members have described the KPOT code as overpriced, UNKN and the REvil gang have money to spare.
The REvil member, who has been operating as the ransomware gang’s public figurehead and recruiter for the past two years on hacking forums, has recently given an interview to a Russian YouTube channel, claiming that the REvil gang makes more than $100 million from ransom demands each year [1, 2].
UNKN also claimed the gang fears assassinations more than they fear a law enforcement action. More

Voters across multiple US states have been targeted today by robocalls telling them to stay home or come vote tomorrow, on Wednesday, due to massive turnouts and long lines at voting stations.
US citizens and authorities have reported robocalls messages in nine states, including Florida, Georgia, Iowa, Kansas, Michigan, Nebraska, New York, New Hampshire, and North Carolina.
In response to the reports, state officials have taken today to social media to dispel the misinformation shared in the robocalls, urging voters to vote in-person by 8 PM ET today, the last day of voting, and not follow the advice shared in some calls, which was trying to mislead voters by tricking them to come vote tomorrow — after polls were set to close.

We received reports that an unknown party is purposefully spreading misinformation via robocalls in Flint in an attempt to confuse voters.Let me be clear — if you plan to vote in-person, you must do so, or be in line to do so, by 8PM today.
— Governor Gretchen Whitmer (@GovWhitmer) November 3, 2020

NOTICE: We are receiving reports of robocalls telling voters to stay home. Disregard these calls. If you have not already voted, today is the day! Polls in Kansas close at 7:00 p.m. local time.Find your polling location here: https://t.co/PWjjT24hmw #Election2020 #ksleg
— KS Sec. of State (@KansasSOS) November 3, 2020

However, while some messages were specifically trying to mislead voters to show up to vote on the wrong day, the vast majority of robocalls featured even simpler messages that merely tried to convince voters to stay home.
The message, which didn’t mention the voting process in an obvious attempt to avoid a possible law enforcement investigation, said: “This is just a test call. Time to stay home. Stay safe and stay home.”

UPDATE: I’m collecting confirmed robocalls to voters in Massachusetts, New York, New Hampshire, Michigan, Nebraska and Georgia among others. Will continue to update. pic.twitter.com/tZ9DsV7eWQ
— John Scott-Railton (@jsrailton) November 3, 2020

According to the Washington Post, more than 10 million robocalls of this type have been placed today.
US officials, including the Federal Bureau of Investigation (FBI) and the Federal Communications Commission (FCC), said they are aware of the campaigns and looking into the matter.
DHS says this happened before

Nevertheless, the issue doesn’t seem to alarm US federal officials too much either.
According to a Cyberscoop report, speaking on background in a press conference today, DHS officials said robocall campaigns had taken place each election cycle, and this one was not out of the ordinary.
Some of these campaigns started even before the voting process.
For example, Michigan Attorney General Dana Nessel filed official charges on October 1 against two Republican operatives for their role in a recent campaign targeting minority voters in Michigan this fall.
Nessel identified the suspects as Jack Burkman, 54, of Virginia and Jacob Wohl, 22, of California, who, if found guilty, face up to 24 years behind bars.
According to a Reuters report, the FBI is formally investigating today’s new wave of robocall campaigns.
Federal agencies like CISA and the FBI also said that despite a few malfunctions here and there, today’s election process has not been marred by cyber-security issues. More

Image: deepanker70
Google has released security updates for the Chrome for Android browser to fix a zero-day vulnerability that is currently exploited in the wild.
Chrome for Android version 86.0.4240.185 was released last night with fixes for CVE-2020-16010, a heap buffer overflow vulnerability in the Chrome for Android user interface (UI) component.
Google said the bug was exploited to allow attackers to bypass and escape the Chrome security sandbox on Android devices and run code on the underlying OS.
Details about the attack are not public to give Chrome users more time to install the updates and prevent other threat actors from developing exploits for the same zero-day.

A few people noticed that CVE-2020-16010 wasn’t included in the link above. That’s because Chrome has separate release notes for Desktop and Android. The release notes covering CVE-2020-16010 (sandbox escape for Chrome on Android) are now available here: https://t.co/6hBKMuCAaK
— Ben Hawkes (@benhawkes) November 3, 2020

Google credited its internal Threat Analysis Group (TAG) team for discovering the Chrome for Android zero-day attacks.
This marks the third Chrome zero-day discovered by the TAG team in the past two weeks.
The first two zero-days affected only Chrome for desktop versions.

The first was patched on October 20, was tracked as CVE-2020-15999, and affected Chrome’s FreeType font rendering library.
In a follow-up report last week, Google said this first Chrome zero-day was utilized together with a Windows zero-day (CVE-2020-17087) as part of a two-step exploit chain, with the Chrome zero-day allowing attackers to execute malicious code inside Chrome, while the Windows zero-day was used to elevate the code’s privileges and attack the underlying Windows OS.
On top of this, Google also patched a second zero-day yesterday. Tracked as CVE-2020-16009, this zero-day was described as a remote code execution in the Chrome V8 JavaScript engine.
Hours after the Chrome team released patches for this second zero-day, Google revealed a third zero-day, impacting only its Chrome for Android version.
While the three zero-days are all different from each other and impact different Chrome versions and components, Google did not clarify if all zero-days are exploited by the same threat actor or by multiple groups.
Such details are usually revealed months after patches, via reports published on Google’s Project Zero and Google Security blogs. In the meantime, Chrome users, both on Android and on desktop, should hurry to install the latest updates (v86.0.4240.185 on Android and v86.0.4240.183 on desktop). More

Screengrab of the GrowDiaries website
GrowDiaries, an online community where marijuana growers can blog about their plants and interact with other farmers, has suffered a security breach in September this year.
The breach occurred after the company left two Kibana apps exposed on the internet without administrative passwords.
Kibana apps are normally used by a company’s IT and development staff, as the app allows programmers to manage Elasticsearch databases via a simple web-based visual interface.
Due to its native features, securing Kibana apps is just as important as securing the databases themselves.
But in a report published today on LinkedIn, Bob Diachenko, a security researcher known for discovering and reporting unsecured databases, said GrowDiaries failed to secure two of its Kibana apps, which appear to have been left exposed online without a password since September 22, 2020.
Diachenko says these two Kibana apps granted attackers access to two sets of Elasticsearch databases, with one storing 1.4 million user records and the second holding more than two million user data points.
The first exposed usernames, email addresses, and IP addresses, while the second database also exposed user articles posted on the GrowDiaries site and users’ account passwords.

While the passwords were stored in a hashed format, Diachenko said the format was MD5, a hashing function known to be insecure and crackable (allowing threat actors to determine the cleartext version of each password).

Image: Bob Diachenko
Diachenko said he reported the exposed Kibana apps to GrowDiaries on October 10, with the company securing its infrastructure five days later.
The Ukrainian security researcher said that while GrowDiaries did intervene to secure its server, the company refused other communications, so he was unable to determine if someone else accessed the company’s Elasticsearch databases to download user data.
However, Diachenko said that something like this happening was “likely” as he is certainly not the only one looking for accidentally exposed databases.
A GrowDiaries spokesperson did not return an additional request for comment from ZDNet before this article’s publication.
GrowDiaries users are advised to change their passwords, just in case the data made it into someone else’s hands. With the passwords stored in MD5 format, their old passwords are not secure, and accounts are in danger of getting hijacked. More

Almost two thirds of vulnerabilities on enterprise networks involve flaws which are over two years old which have not been patched, despite fixes being available. This lack of patching is putting businesses at risk of attacks which could often be easily avoided if security updates were applied.
Analysis by Bitdefender found that 64 percent of all reported unpatched vulnerabilities during the first half of 2020 involve known bugs dating from 2018 and previous years, which means organisations are at risk from flaws that somebody should have fixed a long time ago.
“The vast majority of organizations still have unpatched vulnerabilities that were identified anywhere between 2002 and 2018,” the report said.
Applying patches can be time-consuming, tedious and unrewarding work. But for cyber criminals, unpatched vulnerabilities provide a simple way to deploy cyber attacks and malware. But while businesses and users are encouraged to apply security patches to operating systems and software as soon as possible, the figures in Bitdefender’s 2020 Business Threat Landscape Report suggests that some organisations are still slow to apply them.
SEE: Security Awareness and Training policy (TechRepublic Premium)
“With organizations having most of their workforce remote, setting and deploying patching policies has never been more crucial. With six in 10 organizations having machines with unpatched vulnerabilities that are older than 2018, the risks of having those vulnerabilities exploited by threat actors are higher than ever,” the report warned.
In some cases, organisations don’t apply security patches because they fear it could have a negative impact on how they run their systems – and therefore run the risk of a cyber attack instead.

“Backward compatibility plays a vital role in deciding whether or not some applications should be patched. For example, patching or upgrading an application or service could break compatibility with other software that could be mission-critical for the organization. In this case, not patching could be less of a security decision but more of a business decision,” Liviu Arsene, global cybersecurity researcher at Bitdefender told ZDNet.
However, by having a good knowledge of what the network looks like and having a plan to apply patches organisations can go a long way to protecting themselves from falling victim to cyber attacks designed to take advantage if known vulnerabilities.
“Having a patching policy and roll out procedure in place is always the best solution for addressing known vulnerabilities,” said Arsene.
“Systems that are mission-critical but cannot be patched for backward compatibility or business continuity reasons should be isolated and access to them tightly regulated,” he added.
READ MORE ON CYBERSECURITY More

Google Project Zero, the Google security team that finds bugs in all popular software, has disclosed what it classes a high-severity flaw on GitHub after the code-hosting site asked for a double extension on the normal 90-day disclosure deadline.
The bug in GitHub’s Actions feature – a developer workflow automation tool – has become one of the rare vulnerabilities that wasn’t properly fixed before Google Project Zero’s (GPZ) standard 90-day deadline expired. Over 95.8% of flaws are fixed within the deadline, according to Google’s hackers.    

GPZ is known to be generally strict with its 90-day deadline, but it appears GitHub was a little lax in its responses as the deadline approached after Google gave it every chance to fix the bug.
SEE: Virtual hiring tips for job seekers and recruiters (free PDF) (TechRepublic)
As detailed in a disclosure timeline by GPZ’s Felix Wilhelm, the Google security team reported the issue to GitHub’s security on July 21 and a disclosure date was set for October 18. 
According to Wilhelm, Actions’ workflow commands are “highly vulnerable to injection attacks”.
“As the runner process parses every line printed to STDOUT looking for workflow commands, every GitHub action that prints untrusted content as part of its execution is vulnerable. In most cases, the ability to set arbitrary environment variables results in remote code execution as soon as another workflow is executed,” wrote Wilhelm. 

“I’ve spent some time looking at popular GitHub repositories and almost any project with somewhat complex GitHub actions is vulnerable to this bug class.”
GitHub issued an advisory on October 1 and deprecated the vulnerable commands, but argued that what Wilhelm had found was in fact a “moderate security vulnerability”. GitHub assigned the bug the tracking identifier CVE-2020-15228.  
On October 12, GPZ contacted GitHub and proactively offered it a 14-day grace period if GitHub wanted more time to disable the vulnerable commands, according to Wilhelm. 
GitHub then took up the offer of a grace period, and per Wilhelm, it hoped to disable the vulnerable commands after October 19. GPZ then set the new disclosure date to November 2. 
Then on October 28, GPZ alerted GitHub that the deadline was expiring the following week but got no response. 
Due to lack of official response from GitHub, Project Zero contacted informal GitHub contacts who said “the issue is considered fixed and that [GPZ] are clear to go public on 2020-11-02 as planned”, explained Wilhelm. 
SEE: 10 tech predictions that could mean huge changes ahead
But then a day before deadline, GitHub gave its official response and requested a further two days to notify customers of a fix at a future date. 
“GitHub responds and mentions that they won’t be disabling the vulnerable commands by 2020-11-02. They request an additional 48 hours, not to fix the issue, but to notify customers and determine a ‘hard date’ at some point in the future,” wrote Wilhelm. 
So GPZ on Monday proceeded to disclose the bug it reported because it can’t, as per its policy, offer an extension beyond the 104 days – 90 days plus 14 days’ grace. 
“Grace periods will not be granted for vulnerabilities that are expected to take longer than 104 days to fix,” Google Project Zero states on its 2020 disclosure policy.  More

The UK’s National Cyber Security Centre (NCSC) is ‘stepping up support’ for the National Health Service to help protect UK hospitals and other healthcare organisations against cyberattacks.
The NCSC’s Annual Review 2020 reveals that the cyber arm of GCHQ has handled more 200 cyber incidents related to coronavirus during the course of this year – almost a third of the total number of incidents it was called in to help with over that period.

More on privacy

And due to the urgency of securing healthcare during the coronavirus pandemic, the NCSC has been helping the NHS to secure itself against cyberattacks.
SEE: Network security policy (TechRepublic Premium)
That includes performing threat hunting on 1.4 million NHS endpoints in an effort to detect potentially suspicious activity and scanning over one million NHS IP addresses to detect cybersecurity weaknesses.
“The second half of the year for us, as it has for everyone else, has been dominated by the response to COVID,” said Lindy Cameron, CEO of the NCSC.
“What we’ve done as an organisation is really pivot towards the health sector to try and give them the best support we can in thinking about their cyber defence to let them focus on responding to the pandemic,” she added.

The NCSC also helped roll out Active Cyber Defence services, including Web Check, Mail Check and protective DNS, to 235 front-line health bodies across the UK, including NHS Trusts to help protect them against phishing attacks and other threats.
“We’ve taken our active cyber-defence portfolio and pivoted it towards the health sector with 230 health bodies using our active cyber defence. That’s all part of the support we’ve given to NHS Digital to help them help the health sector,” Dr Ian Levy, NCSC technical director, told ZDNet.
“We’re stepping up our support quite significantly,” he continued, adding: “Obviously it’s still for individual trusts to protect themselves along with NHS Digital and ourselves, but we’re really trying to take them the knowledge about the threat and actioning support in the sector at large”.
More than 160 instances of high-risk vulnerabilities have been shared with NHS Trusts during the course of this year while the NCSC has also had to to deal with over 200 incidents related to the UK’s coronavirus response – including Russian cyber espionage targeting coronavirus vaccine development.
The 200 coronavirus-related incidents make up a significant chunk of the total number of 723 cyberattacks involving almost 1,200 victims that the NCSC has helped deal with during the course of the past year, a figure up from 658 in the previous year – and the highest number of incidents since the NCSC was set up. It’s also a number that’s likely to continue rising as cyber criminals get more ambitious.
SEE: A winning strategy for cybersecurity (ZDNet special report) | Download the report as a PDF (TechRepublic)
The review also notes that the NCSC has dealt with three times more ransomware attacks than it did last year as attacks become more targeted and more aggressive.
“The expertise of the NCSC, as part of GCHQ, has been invaluable in keeping the country safe: enabling us to defend our democracy, counter high levels of malicious state and criminal activity, and protect against those who have tried to exploit the pandemic,” said Jeremy Fleming, director of GCHQ.
“The years ahead are likely to be just as challenging, but I am confident that in the NCSC we have developed the capabilities, relationships and approaches to keep the UK at the forefront of global cybersecurity,” he added.
MORE ON CYBERSECURITY More

Image: FireEye
FireEye, one of today’s top cybersecurity companies, has released a new pre-configured virtual machine (VM) that was specifically set up to help threat intelligence analysts hunt down adversaries.

Named the ThreatPursuit VM, this is a Windows 10 installation that comes with more than 50 software programs that are commonly used by threat intel analysts.
The idea behind ThreatPursuit is to provide companies with a ready-made OS that can be deployed to new workstations before, during, or after a security incident and provide threat intel analysts with a ready-to-use work environment.
For example, ThreatPursuit could be deployed to tens or hundreds of machines at the same time and scale up a security firm’s incident response capabilities.
It can also be deployed on computers inside a customer’s network when providing incident response in a remote location, where a victim company may be lacking a threat analysis environment.
ThreatPursuit comes preinstalled with a wide range of tools
More than 50 tools are currently included with ThreatPursuit. The tools range across multiple categories.
There are tools preinstalled in ThreatPursuit that can be used by threat intel analysts to feed indicators of compromise (IOCs) like URLs and file hashes into local or remote MISP platforms.

There are also tools that can allow analysts to see connections between servers and malware samples using visual graphs. And there are tools that can be used to emulate attackers and their intrusion patterns against a company’s network.
The full list of tools is below, as available today on ThreatPursuit’s GitHub repository:
Development, Analytics and Machine Learning Tools:
Shogun
Tensorflow
Pytorch
Rstudio
RTools
Darwin
Keras
Apache Spark
Elasticsearch
Kibana
Apache Zeppelin
Jupyter Notebook
MITRE Caret
Python (x64)
Visualisation Tools:
Constellation
Neo4J
CMAP
Triage, Modelling & Hunting Tools:
MISP
OpenCTI
Maltego
Splunk
MITRE ATT&CK Navigator
Greynoise API and GNQL
threatcrowd API
threatcmd
ViperMonkey
Threat Hunters Playbook
MITRE TRAM
SIGMA
YETI
Azure Zentinel
AMITT Framework
Adversarial Emulation Tools:
MITRE Calderra
Red Canary ATOMIC Red Team
MITRE Caltack Plugin
APTSimulator
FlightSim
Information Gathering Tools:
Maltego
nmap
intelmq
dnsrecon
orbit
FOCA
Utilities and Links:
CyberChef
KeepPass
FLOSS
peview
VLC
AutoIt3
Google Chrome
OpenVPN
Sublime
Notepad++
Docker Desktop
HxD
Sysinternals
Putty
Installation instructions are included in this FireEye blog post.
Third VM image released by FireEye
This is the third ready-made VM image that FireEye has crafted for security purposes and released as open source software.
In 2018, FireEye released FLARE VM, another Windows 10 image that was specifically pre-configured to come with all the tools security researchers need to crack and analyze malware samples.
In 2019, FireEye also released Commando VM, a Windows 10 VM image that came preinstalled with all the major offensive hacking and penetration-testing tools. This VM was specifically built for “red teams” — a term that describes security researchers who perform on-demand penetration tests against a customer’s network to test a company’s defenses and detection capabilities.
With ThreatPursuit VM, FireEye has now released VM images for all the major cyber-security job categories, all to help security practitioners simplify and automate their daily work routines. More