With names, email addresses, and mobile numbers from underground databases, one person in five is at risk of account compromise even with SMS two-factor authentication in place.

Companies that rely on texts for a second factor of authentication are putting about 20% of their customers at risk because the information necessary to attack the system is available in compromised databases for sale on the Dark Web.  

About 1 billion records synthesized from online databases — representing about one in every five mobile phone users in the world — contain users' names, email addresses, passwords, and phone numbers. This gives attackers everything they need to conduct SMS-based phishing attacks, also known as smishing, says Thomas Olofsson, CTO of cybersecurity firm FYEO. 

Cybersecurity experts have long known that the addition of an SMS one-time password is a weak form of two-factor authentication and the simplest form of two-factor authentication for attackers to compromise. However, combining such attacks with the readily available information on users produces a "perfect storm" for attacking accounts, he says.

At Black Hat USA, Olofsson plans to go over findings from research into the problem during a session on Wednesday, Aug. 10, called "Smishmash — Text-Based 2FA Spoofing Using OSINT, Phishing Techniques, and a Burner Phone."

"The research that we have done is two parts: How do you bypass 2FA, and how many phone numbers can we tie to an email address and a password," he tells Dark Reading. "So, for about one in five — a billion — people, we can connect your email address to your phone number, and that is really bad."

The analysis found that by collecting information from known databases of compromised usernames and passwords, researchers could create a database of 22 billion credentials. Linking those credentials to a phone number reduced the exposure to a bit more than 1 billion records, of which about half have been verified.

To make use of those records, attackers can conduct an adversary-in-the-middle attack, where the smishing attack goes to a proxy. When a targeted user opens a link in a malicious SMS message on a mobile device, browsers on iOS and Android rarely show any security information, such as a the URL, since screen real estate is so small. Because of that, few — if any — signs of the attack are presented to the user, making the attacks much more effective, Olofsson says.

In addition, smishing attacks are seven times more likely to succeed than phishing attacks conducted through email, he says.

"It makes it extremely likely that someone will click on the link," Olofsson says. "I even look at our attacks, and I said, wow, I could fall for this."

Attackers have used smishing to compromise financial accounts — especially those linked to cryptocurrency exchanges — during the past two years, with more than $1.6 billion of crypto stolen so far in 2022, according to an analysis published in May. 

**SMS for 2FA: Risky Biz**

Meanwhile, the US federal government has already put additional restrictions on any use of SMS for a second factor of authentication. In 2016, the National Institute of Standards and Technology (NIST) warned against using one-time passwords sent as text messages for a second factor to authenticate users.

"An SMS sent from a mobile phone might seamlessly switch to an internet message delivered to, say, a Skype or Google Voice phone number. Users shouldn't have to know the difference when they hit send — that’s part of the Internet’s magic. But it does matter for security," NIST wrote in an explanation of the policy, adding: "While a password coupled with SMS has a much higher level of protection relative to passwords alone, it doesn't have the strength of device authentication mechanisms inherent in the other authenticators allowable" by NIST guidelines.  

To make it less likely that such attacks succeed, users should ignore any notifications that come through SMS and instead log directly into their account.

"Never trust an SMS message," Olofsson says. "If you feel something is wrong, don't click on it, don't trust it. Go on a computer, and see if you have an e-mail, because at least you can verify the headers then."

Unfortunately, many financial institutions and other companies make it hard for users to implement better security because they only offer SMS as an option for the second factor of authentication. Adding reCAPTCHA checks can give users a hint that something is wrong, Olofsson notes, because any adversary-in-the-middle attack will display the proxy server, not the user's IP address.

Stolen Data Gives Attackers Advantage Against Text-Based 2FA

Over the past few weeks, a Mirai variant appears to have made a pivot from infecting new servers to maintaining remote access.

Tracked by analysts since mid-June, RapperBot malware has spread through brute-force attacks on SSH servers. The IoT botnet targets devices running on ARM, MIPS, SCARC, and x86 architectures, researchers warn.

The malware is a Mirai variant with a few notable, novel features, including ditching the typical Telnet server brute-force approach in favor of attacking SSH servers instead. Fortinet Labs analysts said that since July, RapperBot has changed up its approach from infecting as many servers as possible to maintaining remote access to those compromised SSH servers.

The malware gets its name from a URL that led to a YouTube rap video in early versions, the researchers explained.

"Due to some significant and curious changes that RapperBot has undergone, its primary motivation is still a bit of a mystery," the Fortinet advisory on RapperBot said. "Regardless, since its primary propagation method is brute forcing SSH credentials, this threat can easily be mitigated by setting strong passwords for devices or disabling password authentication for SSH (where possible)."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Fresh RapperBot Malware Variant Brute-Forces Its Way Into SSH Servers

Development of digital gateways to protect the places where we live, work, and converse need to be secure and many doors need to offer restricted access.

What our homes mean to us has been redefined over the COVID era. We now work, rest, and play within its boundaries, not only with family, but also with friends and colleagues in real life or through our computers and connected devices. This "open door" policy, spurred by the pandemic, shows no signs of abating. As a result, our homes are vulnerable in several new ways, and we need to ensure our "new normal" doesn't take advantage of our hospitality.

Homes are also becoming smarter; we're inviting in more technology that is viewing, analyzing, and understanding our daily lives: Think Ring doorbells, Alexas, Zoom, Teams, and banking apps. We are giving technology permission to have some amount of control over and insight into our lives — to do this, they need to be connected and therefore we are introducing more open doors for potentially uninvited guests.

For these reasons, Home Gateways are vital to homes in order to ensure the four walls we live in are protected from digital thieves in the same way that our front doors protect our homes. However, these Home Gateway systems will only work within the Internet of Things (IoT) if the systems and standards that link them enable clarity, comprehension, and collaboration between providers and end users. Unlike our physical homes, there are many ways into our digital home networks, and we only want invited guests.

**Building on the Baseline**

The growing concern regarding the increasing number of Internet-connected devices prompted a number of ETSI members to bring their experience in national guidance and security development together to develop EN 303 645 to act as a baseline for all IoT devices. The aim was to bring all IoT devices to the market with a level of security that started to take away uncertainty for the end user, to offer a device that provides a level of security and helps police the open doors.

However, as our homes become a more complex environment, which moves beyond the IoT, this baseline needs to be built upon. This is why ETSI created TS 103 848 to provide the opportunity to build higher and deeper defenses for now and in the future. Developed by the CYBER Technical Committee, it builds out guidance and examples of the application of the baseline and beyond, most recently encouraging a formal template to make it clear where the baseline is extended or, in rare cases, where it doesn't apply. The first related standard addressed smartphones and was released at the end of last year; the next one will focus on smart door locks. The technical specifications will secure physical devices between the in-home network and the public network, as well as the traffic between these networks, which is vital to home security.

What has been developed with this new Home Gateway security document is important in that it makes it possible to achieve a high level of baseline security at the border of the Internet and home, which is integral to our new digital homes staying secure. It also strengthens the idea that simple security models developed to be universal can be extended and applied to vertical domains without invalidating the universal model. During the entire development of the Home Gateway requirements, and continuing in the development of test and validation of the requirements, there has been involvement from all parts of the stakeholder community. This means developers, manufacturers, operators, regulators, and testers have all come together to make the common baseline and set up for the future.

**Staying Secure**

Home Gateways are the first line of security defense for connected IoT and other home devices. While a secure Home Gateway does not remove the need for strong security of local devices connected to the gateway, it can provide protection against vulnerability for legacy devices or for those devices that cannot otherwise be secured. A secure Home Gateway is therefore a key security layer of the connected home. In a world where IoT devices are in every room of our households, measures to secure them and protect citizens from malicious attacks are of the essence.

Protecting our home is something we can never be complacent about and the Home Gateway addresses and keeps secure the gateways and windows into our lives that the digital world offers. Thus, the age-old promise of the ideal work-life balance has been brought closer with the hybrid of work from home, the occasional commute, flexible working hours, and a secure Internet starting with the basics of a secure Home Gateway.

**Further Information**

The ETSI consumer cybersecurity standard is supplemented by a test specification to help manufacturers pass certification schemes, a guide to facilitate implementation, and a template to better develop future vertical standards, within the committee or other standardization bodies.

*   To help manufacturers and other stakeholders, the ETSI CYBER technical committee has also released a Technical Report, ETSI TR 103 621 **\[Note: PDF download\],** to provide guidance to implement the provisions in ETSI EN 303 645.
*   To help develop other vertical standards, ETSI has created a template **\[Note: Word doc download\]** providing a structured way to extend EN 303 645 for the vertical domain.

A Digital Home Has Many Open Doors

This Tech Tip outlines how DevOps teams can address security integration issues in their CI/CD pipelines.

DevOps teams are familiar with the ways security concerns and process issues can stall CI/CD operations. Operational hurdles that lead to miscommunication between team members and the broader organization are all too common in DevOps pipelines. One of the leading operational issues DevOps teams encounter are permission issues.

Permission issues are a seemingly small, yet significant, roadblock to smooth CI/CD pipelines. If you fail to address them, the result is a lack of cohesion between development and organizational objectives.

Here's how to streamline these processes, boost security integration within the broader CI/CD framework, and maintain robust security postures.

**Review Pipeline Tools**

The DevOps cycle contains several tools with different access needs and permissions. Jeremy Hess, head of developer relations at secrets management platform Akeyless, calls this a "secrets sprawl."

"The combination of proliferation and decentralization of secrets creates an operational burden, if not a nightmare," Hess says. "For organizations that operate in both a cloud-native environment and classic IT infrastructure, a duplication issue is created due to having their own secrets managed with different tools and cloud-native solutions."

There is also the risk of these tools exposing user credentials and permissions to malicious actors. For instance, configuration tools like Jenkins use plugins to determine access and artifact deployment. Thanks to communicating with other pipeline tools, credential details can be present in configuration details.

Developer passwords are not visible on the front end but are accessible from the system. Any user with "configure" permissions can request a credential and inject them into agents. The result is that AWS keys, git credentials, and passwords are at risk.

What to Do:

*   The first step is to delete hardcoded secrets from CI/CD tool files.
*   Distributing secrets between multiple tool config files also reduces the possibility of attack while easing developer and engineer access.
*   Password managers are also a good choice, but validate them for security before implementing a solution.

**Practice Least-Privilege Access**

Access issues often create a lot of frustration among DevOps teams as they are forced to assign blanket access to the majority irrespective of the member's role or job function. While this situation encourages rapid development, it creates massive security issues.

Balancing security with CI/CD needs is tough to get right. That's where the principle of least privilege comes in. Team members receive access to secrets on a need-to-know basis. Note that this principle applies to everything from apps to systems and connected devices.

While most teams put this principle into practice, they leave their process intact. The lack of access audits, not the level of access, creates DevOps frustration.

What to Do:

*   CISOs should regularly involve DevOps teams when reviewing access to mitigate issues quickly. Embedding a security role within every delivery team will mitigate access-related risks quickly. The security team member will have insights into risk-based access needs and can quickly approve or reject requests.
*   Creating an access management repository will also remove any confusion related to role-based access. In addition, record time-based and task-based access permissions in the repository. The result is every DevOps team member will understand their access paths before projects get started. It allows them time to offer feedback and request one-off access to sensitive secrets.
*   Review segmentation rules within your systems when assigning role-based access. Often, these rules will have to change depending on delivery timelines. Involving all stakeholders in these discussions is good practice and prevents frustration down the road.

Implementing one-time passwords (OTPs) and other authentication factors is also a good idea when validating user access to secrets.

**Review OSS Projects**

Open source projects are essential to industry growth but might pose security risks if access is mismanaged. Zan Markan, developer advocate at CI platform CircleCI, summarizes the problem aptly.

"Often the company that initiated and owns a popular OSS project continues to employ the core contributors," Markan writes. "They will probably be joined by other regular contributors and maintainers that are not part of that company. And then there is everyone else — anyone who occasionally might contribute a fix or a feature."

As user access grows, security concerns grow exponentially. Enforcing rigid user-based access is unrealistic and detrimental to an OSS project.

What to Do:

*   CISOs or other security-focused managers must review whether sensitive secrets are being passed during builds for pull requests. Monitoring who can place requests and the roles that review them will ensure a good level of security.
*   Establishing machine identity is also critical, given the degree of non-human access pipelines require. Authentication can be based on verifying whether client runtime container attributes match the characteristics of the valid container. Once authenticated, role-based access can take over, limiting access to secrets.
*   It's also a good policy to destroy containers and virtual machines (VMs) after they've been used.

**Streamlining DevOps Operations Is a Top Priority**

DevOps is critical to every organization's success. Access and permission-related issues are common occurrences that are easily avoided. Reviewing access and establishing a balance between delivery and operational needs is essential to maintaining a competitive edge.

How to Resolve Permission Issues in CI/CD Pipelines

At Black Hat USA, Igal Gofman plans to address how machine identities in the cloud and the explosion of SaaS apps are creating risks for IAM, amid escalating attention from attackers.

Cybercriminals always look for blind spots in access management, be they misconfigurations, poor credentialing practices, unpatched security bugs, or other hidden doors to the corporate castle. Now, as organizations continue their modernizing drift to the cloud, bad actors are taking advantage of an emerging opportunity: access flaws and misconfigurations in how organizations use cloud providers' identity and access management (IAM) layers.

In a talk on Wednesday, Aug. 10 at Black Hat USA entitled "IAM The One Who Knocks," Igal Gofman, head of research for Ermetic, will offer a view into this emerging risk frontier. "Defenders need to understand that the new perimeter is not the network layer as it was before. Now it's really IAM — it's management layer that governs all," he tells Dark Reading.

**Complexity, Machine Identities = Insecurity**

The most common pitfall that security teams step into when implementing cloud IAM is not recognizing the sheer complexity of the environment, he notes. That includes understanding the ballooning amount of permissions and access that software-as-a-service (SaaS) apps have created.

"Adversaries continue to put their hands on tokens or credentials, either via phishing or some other approach," explains Gofman. "At one time, those didn't give much to the attacker beyond what was on a local machine. But now, those security tokens have much more access, because everyone in the last few years moved to the cloud, and have more access to cloud resources."

The complexity issue is particularly piquant when it comes to machine entities — which, unlike humans, are always working. In the cloud context, they're used to access cloud APIs using API keys; enable serverless applications; automate security roles (i.e., cloud access service brokers or CASBs); integrate SaaS apps and profiles with each other using service accounts; and more.

Given that the average company now uses hundreds of cloud-based apps and databases, this mass of machine identities presents a highly complex web of interwoven permissions and access that underpin organizations' infrastructures, which is difficult to gain visibility into and thus difficult to manage, Gofman says. That's why adversaries are seeking to exploit these identities more and more.

"We are seeing a rise in the use of non-human identities, which have access to different resources and different services internally," he notes. "These are services that speak with other services. They have permissions, and usually broader access than humans. The cloud providers are pushing their users to use those, because at the basic level they consider them to be more secure. But, there are some exploitation techniques that can be used to compromise environments using those non-human identities."

Machine entities with management permissions are particularly attractive for adversaries to use, he adds.

"This is one of the main vectors we see cybercriminals targeting, especially in Azure," he explains. "If you don't have an intimate understanding of how to manage them within the IAM, you're offering up a security hole."

**How to Boost IAM Security in the Cloud**

From a defensive standpoint, Gofman plans to discuss the many options that organizations have for getting their arms around the problem of implementing effective IAM in the cloud. For one, organizations should make use of cloud providers' logging capabilities to build a comprehensive view of who — and what — exists in the environment.

"These tools are not actually used extensively, but they're good options to better understand what's going on in your environment," he explains. "You can use logging to reduce the attack surface too, because you can see exactly what users are using, and what permissions they have. Admins can also compare stated policies to what is actually being used within a given infrastructure, too."

He also plans to break down and compare the different IAM services from the top three public cloud providers — Amazon Web Services, Google Cloud Platform, and Microsoft Azure — and their security approaches, all of which are slightly different. Multi-cloud IAM is an added wrinkle for corporations using different clouds from different providers, and Gofman notes that understanding the subtle differences between the tools they offer can go a long way to shoring up defenses.

Organizations can also use a variety of third-party, open source tools to gain better visibility across the infrastructure, he notes, adding that he and his co-presenter Noam Dahan, research lead at Ermetic, plan to demo one option.

"Cloud IAM is super-important," Gofman says. "We're going to speak about the dangers, the tools that can be used, and the importance of understanding better what permissions are used and what permission are not used, and how and where admins can identify blind spots."

Cyberattackers Increasingly Target Cloud IAM as a Weak Link

A month after the algorithms were revealed, some companies have already begun incorporating the future standards into their products and services.

A month after the National Institute of Standards and Technology (NIST) revealed the first quantum-safe algorithms, Amazon Web Services (AWS) and IBM have swiftly moved forward. Google was also quick to outline an aggressive implementation plan for its cloud service that it started a decade ago.

It helps that IBM researchers contributed to three of the four algorithms, while AWS had a hand in two. Google contributed to one of the submitted algorithms, SPHINCS+.

A long process that started in 2016 with 69 original candidates ends with the selection of four algorithms that will become NIST standards, which will play a critical role in protecting encrypted data from the vast power of quantum computers.

NIST's four choices include CRYSTALS-Kyber, a public-private key-encapsulation mechanism (KEM) for general asymmetric encryption, such as when connecting websites. For digital signatures, NIST selected CRYSTALS-Dilithium, FALCON, and SPHINCS+. NIST will add a few more algorithms to the mix in two years.

Vadim Lyubashevsky, a cryptographer who works in IBM's Zurich Research Laboratories, contributed to the development of CRYSTALS-Kyber, CRYSTALS-Dilithium, and Falcon. Lyubashevsky was predictably pleased by the algorithms selected, but he had only anticipated NIST would pick two digital signature candidates rather than three.

Ideally, NIST would have chosen a second key establishment algorithm, according to Lyubashevsky. "They could have chosen one more right away just to be safe," he told Dark Reading. "I think some people expected McEliece to be chosen, but maybe NIST decided to hold off for two years to see what the backup should be to Kyber."

**IBM's New Mainframe Supports NIST-Selected Algorithms**

After NIST identified the algorithms, IBM moved forward by specifying them into its recently launched z16 mainframe. IBM introduced the z16 in April, calling it the "first quantum-safe system," enabled by its new Crypto Express 8S card and APIs that provide access to the NIST APIs.

IBM was championing three of the algorithms that NIST selected, so IBM had already included them in the z16. Since IBM had unveiled the z16 before the NIST decision, the company implemented the algorithms into the new system. IBM last week made it official that the z16 supports the algorithms.

Anne Dames, an IBM distinguished engineer who works on the company's z Systems team, explained that the Crypto Express 8S card could implement various cryptographic algorithms. Nevertheless, IBM was betting on CRYSTAL-Kyber and Dilithium, according to Dames.

"We are very fortunate in that it went in the direction we hoped it would go," she told Dark Reading. "And because we chose to implement CRYSTALS-Kyber and CRYSTALS-Dilithium in the hardware security module, which allows clients to get access to it, the firmware in that hardware security module can be updated. So, if other algorithms were selected, then we would add them to our roadmap for inclusion of those algorithms for the future."

A software library on the system allows application and infrastructure developers to incorporate APIs so that clients can generate quantum-safe digital signatures for both classic computing systems and quantum computers.

"We also have a CRYSTALS-Kyber interface in place so that we can generate a key and provide it wrapped by a Kyber key so that could be used in a potential key exchange scheme," Dames said. "And we've also incorporated some APIs that allow clients to have a key exchange scheme between two parties."

Dames noted that clients might use Kyber to generate digital signatures on documents. "Think about code signing servers, things like that, or documents signing services, where people would like to actually use the digital signature capability to ensure the authenticity of the document or of the code that's being used," she said.

**AWS Engineers Algorithms Into Services**

During Amazon's AWS re:Inforce security conference last week in Boston, the cloud provider emphasized its post-quantum cryptography (PQC) efforts. According to Margaret Salter, director of applied cryptography at AWS, Amazon is already engineering the NIST standards into its services.

During a breakout session on AWS' cryptography efforts at the conference, Salter said AWS had implemented an open source, hybrid post-quantum key exchange based on a specification called s2n-tls, which implements the Transport Layer Security (TLS) protocol across different AWS services. AWS has contributed it as a draft standard to the Internet Engineering Task Force (IETF).

Salter explained that the hybrid key exchange brings together its traditional key exchanges while enabling post-quantum security. "We have regular key exchanges that we've been using for years and years to protect data," she said. "We don't want to get rid of those; we're just going to enhance them by adding a public key exchange on top of it. And using both of those, you have traditional security, plus post quantum security."

Last week, Amazon announced that it deployed s2n-tls, the hybrid post-quantum TLS with CRYSTALS-Kyber, which connects to the AWS Key Management Service (AWS KMS) and AWS Certificate Manager (ACM). In an update this week, Amazon documented its stated support for AWS Secrets Manager, a service for managing, rotating, and retrieving database credentials and API keys.

**Google's Decade-Long PQC Migration**

While Google didn't make implementation announcements like AWS in the immediate aftermath of NIST's selection, VP and CISO Phil Venables said Google has been focused on PQC algorithms "beyond theoretical implementations" for over a decade. Venables was among several prominent researchers who co-authored a technical paper outlining the urgency of adopting PQC strategies. The peer-reviewed paper was published in May by Nature, a respected journal for the science and technology communities.

"At Google, we're well into a multi-year effort to migrate to post-quantum cryptography that is designed to address both immediate and long-term risks to protect sensitive information," Venables wrote in a blog post published following the NIST announcement. "We have one goal: ensure that Google is PQC ready."

Venables recalled an experiment in 2016 with Chrome where a minimal number of connections from the Web browser to Google servers used a post-quantum key-exchange algorithm alongside the existing elliptic-curve key-exchange algorithm. "By adding a post-quantum algorithm in a hybrid mode with the existing key exchange, we were able to test its implementation without affecting user security," Venables noted.

Google and Cloudflare announced a "wide-scale post-quantum experiment" in 2019 implementing two post-quantum key exchanges, "integrated into Cloudflare's TLS stack, and deployed the implementation on edge servers and in Chrome Canary clients." The experiment helped Google understand the implications of deploying two post-quantum key agreements with TLS.

Venables noted that last year Google tested post-quantum confidentiality in TLS and found that various network products were not compatible with post-quantum TLS. "We were able to work with the vendor so that the issue was fixed in future firmware updates," he said. "By experimenting early, we resolved this issue for future deployments."

**Other Standards Efforts**

The four algorithms NIST announced are an important milestone in advancing PQC, but there's other work to be done besides quantum-safe encryption. The AWS TLS submission to the IETF is one example; others include such efforts as Hybrid PQ VPN.

"What you will see happening is those organizations that work on TLS protocols, or SSH, or VPN type protocols, will now come together and put together proposals which they will evaluate in their communities to determine what's best and which protocols should be updated, how the certificates should be defined, and things like things like that," IBM's Dames said.

Dustin Moody, a mathematician at NIST who leads its PQC project, shared a similar view during a panel discussion at the RSA Conference in June. "There's been a lot of global cooperation with our NIST process, rather than fracturing of the effort and coming up with a lot of different algorithms," Moody said. "We've seen most countries and standards organizations waiting to see what comes out of our nice progress on this process, as well as participating in that. And we see that as a very good sign."

Amazon, IBM Move Swiftly on Post-Quantum Cryptographic Algorithms Selected by NIST

A dangerous VMware authentication-bypass bug could give threat actors administrative access over virtual machines.

Several VMware products need to be patched against a critical flaw that would allow authentication bypass for on-premises implementations.

The latest VMware bug is being tracked under CVE-2022-31656 and has a CVSSv3 base score of 9.8, according to the company. 

The VMWare advisory reported the products affected include: 

*   VMware Workspace ONE Access (Access)
*   VMware Workspace ONE Access Connector (Access Connector)
*   VMware Identity Manager (vIDM)
*   VMware Identity Manager Connector (vIDM Connector)
*   VMware vRealize Automation (vRA)
*   VMware Cloud Foundation
*   vRealize Suite Lifecycle Manager

"It is extremely important that you quickly take steps to patch or mitigate these issues in on-premises deployments," the company warned in a security advisory. "If your organization uses ITIL methodologies for change management, this would be considered an 'emergency' change."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Time to Patch VMware Products Against a Critical New Vulnerability

The CVE-2022-27535 local privilege-escalation security vulnerability in the security software threatens remote and work-from-home users.

A high-severity local privilege-escalation (LPE) vulnerability in Kaspersky's VPN Secure Connection for Microsoft Windows has been discovered, which would allow an attacker to gain administrative privileges and take full control over a victim's computer.

Tracked as CVE-2022-27535, the bug carries a high-severity CVSS score of 7.8 out of 10, according to an advisory out today from Synopsys, which discovered the issue. It exists in the Support Tools part of the application, and would allow an authenticated attacker to trigger arbitrary file deletion in the system.

"it could lead to device malfunction or the removal of important system files required for correct system operation," according to a Kaspersky spokesperson. "To execute this attack, an intruder had to create a specific file and convince users to run 'Delete all service data and reports' or 'Save report on your computer" product features.'"

While remote code execution (RCE) bugs tend to hog the patching spotlight, LPE flaws deserve recognition as they're often linchpins within a wider attack flow. After cybercriminals gain initial access to a target via RCE or social engineering, LPEs are generally used by attackers to boost their privileges from a normal user profile to SYSTEM – i.e., the highest privilege level in the Windows environment.

With these kinds of local admin privileges, an attacker can then gain further access to the network, and ultimately a company's crown jewels.

"A fully compromised computer would allow an attacker access to websites, credentials, files, and other sensitive information that could be useful by itself, or useful in moving laterally inside a corporate network," Jonathan Knudsen, head of global research at Synopsys Cybersecurity Research Center, tells Dark Reading.

Kaspersky's VPN Secure Connection offers remote workers a supposedly secure way to tie back to a corporate network and resources, and Knudsen notes that the bug discovery points out an important truism: "All software has vulnerabilities, even security software. The key to releasing better, more secure software is using a development process where security is part of every phase."

He adds that Synopsys hasn't seen any exploitation of the bug, but "most likely attackers will take note of it as a possible technique." Users should upgrade to version 21.7.7.393 or later to patch their systems.

High-Severity Bug in Kaspersky VPN Client Opens Door to PC Takeover

Securing email communication has never been more critical for organizations, and it has never been more challenging to do so. Attack volumes have increased and become more sophisticated.

**The Importance of Email Security**

Email remains the primary vehicle used by cybercriminals, with 90% of cyberattacks delivered via this attack vector. Email is also the most essential and widely used business communication tool.

Securing email communication has never been more critical for organizations, and it has never been more challenging to do so. Attack volumes have not only gone up, but the attacks delivered via email have also become more sophisticated.

The work-from-home shift experienced by most of the world has made employees and organizations more vulnerable to cyberattacks delivered by email than ever before. This makes business email an irresistible target for cybercriminals.

**Email Security Is at a Crossroads**

Protecting email, while reducing cost and complexity, is a business-critical objective for organizations of all sizes, working in virtually every industry, and in all areas of the world. Workers are more frequently than ever logging on remotely from home, from hotels, from coffee shops, and sometimes even using their own personal devices. Often distracted by their environment, even the most cautious user can inadvertently open a malicious email or click on a malicious link.

Some organizations are choosing to rely on platforms such as Microsoft 365 and Google Workspace to provide the base of their email security strategy, while others are choosing to rely on more specialized products such as a secure email gateway created by cybersecurity vendors. And while most cybersecurity vendors force customers to choose only their specialized solution in order to reap its benefits, it is completely possible for these vendors to modify their existing specialized solutions to work with well-known software vendor platforms to augment and enhance those platforms’ security to the extreme benefit of their customers.

**Meeting Today's Email Security Needs**

Today's agile organizations desire — and should require — simplicity and effective results from their security tools. And with continual pressure for security leaders to justify their investments in new security technology, email security solutions should be diverse, cost effective, and deliver a quick return. This is all coming at a time when complexity for virtually every security team is increasing. System noise is increasing, the business and compliance needs of organizations are growing more diverse and complicated, and the risk cyberattacks pose is continually on the rise.

Gateway-less email security solutions stand poised to meet these customer needs. These solutions augment the security of software platforms like Microsoft 365 and Google Workspace by reinspecting emails that have already passed through the platform's email gateway and been scanned by its email security tool. These gateway-less email security solutions use routing rules to inspect emails after they have been scanned by the platform's detection engine but before they are delivered to users' inboxes. This helps stop the threats that may have been missed by Microsoft 365, Google Workspace, or other software platform security tools.

Gateway-less email security solutions deliver world-class protection, keeping email communication secure while augmenting the protection of incumbent email providers.

**The Benefits of Gateway-less Email Security**

Gateway-less solutions are growing in popularity due to their ease of deployment, ability to augment rather than replace software platform security, and appeal to organizations of all sizes. Cybersecurity analysts are now recommending gateway-less solutions as a viable email security option.

Gateway-less email security solutions stand behind security solutions organization are already using, helping to reduce the cost and complexity of email security deployments, which can be especially beneficial for smaller organizations with less complex email environments. Gateway-less solutions run entirely in the cloud with little to no infrastructure cost and require little to no security policy customization. This benefits both smaller organizations with lean IT departments and less resources, as well as larger organizations that are looking to cut costs, reduce resource use, and allow critical IT staff to focus on other areas of the enterprise.

When evaluating gateway-less email security solutions, organizations should seek out products that:

*   Deploy in a matter of minutes
*   Block even the most sophisticated email attacks with AI-powered detection
*   Enhance and extend the security of software platforms like Microsoft 365 and Google Workspace
*   Optimize protections with a quality best-practice, out-of-the-box security policy
*   Simplify email security with effortless administration
*   Allow users to easily see what threats have been blocked and why
*   Can be adjusted with the click of a button to meet user and admin needs
*   Defend against social engineering attacks
*   Remediate malicious emails with a single click

**The Bottom Line**

As the work-from-home shift transitions into a much more acceptable, prevalent, and permanent hybrid working environment, some organizations are choosing to stay with a traditional email security gateway, while others are moving toward gateway-less email solutions that augment the security of software platforms like Microsoft 365 and Google Workspace. Organizations that do so should seek out a gateway-less email security partner with advanced detection capabilities, access to long-standing threat intelligence based on long-running market and industry experience, and the ablity to deliver best-in-class efficacy that is difficult to match via a tried-and true solution platform that can reduce complexity, reduce organization risk, and bring email and collaboration security under one roof through a single pane of glass.

**About the Author**

    

Thom Bailey leads the Strategy & Evangelism team at Mimecast, the authority in email security, targeted threat protection, and data governance. With over 20 years in product marketing and product management experience, Thom's passion has been one of understanding the intersection of IT operations and security.

How Email Security Is Evolving

A global network of inauthentic news sites present themselves as independent news outlets, offering content favoring China's government and articles critical of the US.

A fake-news influence campaign based in China is leveraging at least 72 inauthentic news sites to push content strategically aligned with the political interests of the People's Republic of China (PRC) across the globe and in multiple languages.  

The sites are linked to a Chinese public-relations firm called Shanghai Haixun Technology, according to a report from Mandiant, which dubbed the campaign "HaiEnergy." To disseminate the content, the effort makes use of various social-media accounts with hundreds of thousands of followers. 

The purpose of the campaign is to target global audiences with messaging intended to improve the international image of China — and to discredit critics of its policies. According to the new Mandiant report, the campaign narratives include promoting the reform of Hong Kong's electoral system — giving the mainland government more control over choosing candidates — and criticizing the United States and its allies.

At the start of the month, several of the sites published articles critical of US House Speaker Nancy Pelosi's recently concluded trip to Taiwan, warning her to "stay away from Taiwan."

The content also attempts to discredit outspoken government opponents, including German anthropologist Adrian Zenz, who is known for his research on China's autonomous Xinjiang territory in the northwest, where there has been a reported genocide against the Uyghur population.

This was done via website articles and social-media posts, featuring what Mandiant suspects to be "at least three fabricated letters, based on obvious grammatical errors and typos."

One letter was observed being used by a Twitter account belonging to a suspected inauthentic persona "Jonas Drosten" (@Jonas\_drosten), who posted a tweet containing images of three letters. The tweet, and one of the letters, alleges that Adrian received "financial support from US Senator Marco Rubio and former White House Chief Strategist Steve Bannon."  

The Uyghur ethnic minority community has in the past been a target of multiple other disinformation efforts.

**Outsourcing Fake News Efforts**

Mandiant researchers were not able to determine whether Shanghai Haixun Technology is aware of the fakeness of the HaiEnergy effort, but the researchers found evidence that the campaign has leveraged services and infrastructure belonging to the PR firm to host and distribute content.  

The campaign's use of third-party infrastructure allows the operators behind the campaign to obfuscate their identities while distributing content. And the use of a PR firm in this campaign may also be suggestive of recent trends noted by Meta (PDF) regarding the increased outsourcing of influence operations to third parties.

The Mandiant report also notes that actors that use PR firms may also do so to lower the barrier to entry for such activity to actors with limited experience in such areas.

"The campaign does not appear to be particularly sophisticated, as evidenced at least in part by the seeming lack of substantial engagement outside of inauthentic amplification of its content," says Ryan Serabian, senior analyst at Mandiant.  

For instance, some of the social-media accounts outright note that they've been commissioned to promote content, and their bios suggest that they were willing to do "paid promos."

Serabian explains that social-media platforms, governments, and other organizations increasingly look to root out inauthentic information activity, so he expects that actors will adapt new tactics and strategies, like contracting PR firms, to continue to achieve their aims.

"As we've highlighted, such actors might seek to leverage PR firms to distribute content, and they may also become more inventive in the types of content they distribute, such as by way of using technology like artificial intelligence-generated 'deepfake' images and videos," he says.  

This particular operation follows the efforts of Russian operatives, and those allied with Russian interests, which unleashed a deluge of disinformation and fake news to try and sow fear and confusion in Ukraine following the invasion of that nation.

Source

DARKReading