Linus Torvalds says Retbleed has been addressed in the Linux kernel, but code complexity means the release will be delayed by a week to give more time for testing.

Linux kernel developers have successfully addressed Retbleed, the latest Spectre-like speculative execution attack against older AMD and Intel processors, Linus Torvalds wrote in a message to the Linux Kernel Mailing List on Sunday. However, the difficult repair process means there will be a delay of the release for Linux version 5.19 by a week.

"I think we've got the retbleed fallout all handled (knock wood)," Torvalds wrote.

The complexity of the fix wasn't the only reason for the release; there were two other development trees that independently asked for an extension. The other trees that needed the extension involve the btrfs filesystems and firmware for Intel GPU controllers.

"When we've had one of those embargoed \[hardware\] issues pending, the patches didn't get the open development, and then as a result missed all the usual sanity checking by all the automation build and test infrastructure we have," Torvalds explained. "So, 5.19 will be one of those releases that have an additional rc8 next weekend before the final release."

Last week, researchers at ETH Zurich announced the discovery of Retbleed, an addition to the family of speculative execution attacks that began with Meltdown and Spectre. The researchers named the family of these vulnerabilities Spectre-BTI after the attack method: via a branch target injection.

Unlike its siblings, Retbleed does not proceed via indirect jumps or calls, but instead uses return instructions. This is significant because it undermines some of the current Spectre-BTI protections, the researchers wrote.

In response, Intel and AMD issued advisories describing mitigations for CVE-2022-29901 (Intel CPUs) and CVE-2022-2990 (AMD CPUs).

**Speculative Execution Exploits Here to Stay**

The discovery follows Hertzbleed, discovered in June, which exploited a side-channel flaw in Intel and AMD processors, allowing remote attackers with low privileges to infer sensitive information by observing power-throttling changes in the CPU.

The attacks leverage weaknesses in the speculative execution process, a performance optimization technique in modern CPUs.

Other major speculative execution vulnerability exploits uncovered in recent years include Meltdown, Spectre, and SWAPGS.

A team of Google researchers published a deep analysis of the issue back in 2019, positing that chip makers' focus on performance has left microprocessors open to numerous side-channel attacks that cannot be fixed by software updates.

Some experts believe exploits like Spectre and Meltdown will force customers to make tradeoffs between performance and security of applications. They predict these types of threats will become much more dangerous in cloud and virtual environments.

A 2019 survey from Login VSI found patches negatively impacted performance for a fifth of those who applied them, with at times substantial performance reductions.

Retbleed Fixed in Linux Kernel, Patch Delayed

Law enforcement estimates campaign has already bilked cryptocurrency investors out of $42.7 million.

Would-be cryptocurrency investors are being targeted in a scam that has already stolen more than $42.7 million from 244 victims, according to the latest private industry notification from the Federal Bureau of Investigation. 

According to the FBI, scammers have used phishing attacks to convince victims to download fake mobile cryptocurrency investment apps impersonating legitimate investment apps. The victims then deposit cryptocurrency into wallets associated with their accounts on the app, giving the scammers control of the funds. One campaign between December and May used the name and logo of a legitimate company (unnamed in the alert) and defrauded 28 victims of $3.7 million.

When victims attempted to withdraw funds from these accounts, they received messages stating that they needed to pay taxes on their investments first.

The advisory warns legitimate cryptocurrency financial institutions to be on the lookout for these scams and alert the FBI about any attempts to lure investors with fake solicitations. 

"While cryptocurrency steals headlines, the fraudsters are out in force trying to steal them too," Ryan McCurdy of Bolster.ai said in reaction to the FBI alert. "Scammers are becoming more sophisticated in researching companies and targeting employees." 

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

FBI: Beware of Scam Cryptocurrency Investment Apps

An ongoing campaign is actively targeting the vulnerability in the Kaswara Modern WPBakery Page Builder Addon, which is still installed on up to 8,000 sites, security analysts warn.

Although the plug-in is no longer available, the Kaswara Modern WPBakery Page Builder Addons is still running on as many as 8,000 WordPress sites, according to analysts who warn the app's unpatched file upload vulnerability is under active attack. 

The WordPress bug, tracked under CVE-2021-24284, can be used to upload malicious PHP files to an affected website, according to the research team at Wordfence. The vulnerability could lead to code execution and complete site takeover, the researchers warn. The plug-in was closed without a patch and the Wordfence team says all versions are affected by the bug.

Wordfence raised the alarm that it has seen nearly a half-million daily attacks since the beginning of July. The campaign has used the NDSW Trojan to inject code into legitimate JavaScript files and redirect users to malicious domains.

The team stresses this is a "serious vulnerability that can lead to complete site takeover" and that the "developer has not been responsive regarding the patch" in their advisory on the WordPress plug-in. Since it is unlikely the plug-in will ever receive a patch for this critical vulnerability, "the best option is to fully remove the Kaswara Modern WPBakery Page Builder Addons plugin from your WordPress website," the researchers advise. 

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

WordPress Page Builder Plug-in  Under Attack, Can't Be Patched

Feeling creative? Submit your caption and our panel of experts will reward the winner with a $25 Amazon gift card.

We provide the carrot — the chance to win a $25 Amazon gift card — and you provide a possible caption for the cartoon above. It's that simple (and no worries about a stick). Here are four convenient ways to submit your idea:

*   Email _\[email protected\]_ with the subject line "Dark Reading July Toon."
*   Via social media: Twitter, Facebook, and LinkedIn.

The contest ends Wednesday, August 11, 2022. We look forward to your submissions.

**Last Month's Winner**  
We had a record number of submissions for our "Cuter Than a June Bug" caption contest. But, of course, only one person can win, and that person happens to be the very clever Kenny M. Congratulations! A $25 Amazon gift card is on the way.

    

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

Name That Toon: Modern-Day Fable

Telecom and business services see the highest level of attacks, but the two most common ransomware families, which continue to be LockBit and Conti, are seen less often.

Attempted ransomware attacks declined in the first quarter of 2022, as companies continued to be less likely to pay requested ransoms and the war between Russia and Ukraine disrupted the Eastern European groups responsible for a significant share of attacks, endpoint detection-and-response firm Trellix states in a new report. 

Companies continued to encounter the two most common ransomware families — LockBit and Conti — more than a third of the time, but both ransomware attacks are seen far less often, with detections for LockBit dropping by 44% and Conti by 37%, according to Trellix's "Summer 2022 Threat Report." Globally, ransomware targeted the telecom sector in more than half of attacks, but business services dominated the targeting of US organizations, accounting for 64% of detections.

While cybercriminals often avoid politics, the decline likely comes as a result of Russia's invasion of Ukraine, which has led to more geopolitical-related attacks but fewer ransomware campaigns, says Christiaan Beek, lead scientist at Trellix.

"The attacks are shifting," he says. "While we saw some wipers and some other malware, which continued in April and May, they remain fairly low activity, but we are seeing more activity from hacktivism and \[patriot\] groups."

    

Globally, the telecommunications sector is most targeted by ransomware, but in the US, business services are favored. Source: Trellix's Summer 2022 Threat Report

The report from Trellix's Threat Labs is the first analysis from the company to combine data and telemetry from two acquisitions — McAfee Enterprise and FireEye's product business — bought by Symphony Technology Group in 2021. In January, STG renamed the combined businesses Trellix.

The company also includes references to data from a third party — incident response firm Coveware — that shows only 46% of companies paid a ransom in the first quarter of 2022, down from 85% for the same quarter three years ago. The average victim's payment to ransomware groups also declined to $74,000, down more than a third from the fourth quarter of 2021, Coveware stated in a May blog post.

"This is what progress looks like against ransomware. It is slow," the company stated.

**Harder to Compromise Systems**

Nation-state activity continues to be a major threat, according to Trellix's report. Following Russia's invasion of Ukraine — two countries that are thought to be home to several ransomware groups — attacks have focused on a goal of data exfiltration while using cybercrime as a way to fund the effort.

In February, for example, the Conti group publicly posted a statement supporting the Russian government. The following month, a Ukrainian researcher leaked years of Conti's internal chats, showing that the group had dozens of coders, operated like a business, and maintained separate sets of tools to hide the actual size of their operations.

"\[W\]e should consider we might be witnessing the formation of a hybrid group, one that can attack targets chosen by the government, but maintaining the plausible deniability of a crime group after financial gain," Trellix's report states. "The ransomware might have a dual purpose, on the one hand being disruptive in nature and on the other hand serving as a distraction for a data exfiltration operation."

Other major trends include the continued adoption of living-off-the-land (LotL) techniques. While a red-team tool, Cobalt Strike, continues to be the most popular attack tool by far — used in a third (32%) of campaigns — attackers continue to use tools resident on the targeted systems, including Windows Shell, PowerShell, and the Windows Management Interface (WMI), Trellix's report states.

However, attackers do have to work harder to compromise systems, with improving defenses requiring longer attack chains, says Beek. In the past, a victim might click on a link in an email or open an untrusted attachment and have a malicious program installed.

"Now, you see an email with an attachment still, but it has a little script in there that is a URL, for example, and it goes to one website, downloads a little bit of code," Beek says. "There are more stages that are happening before something is definitely being put on the system."

While telecommunications companies and business services are currently the most popular targets of attacks, among the most worrisome trends is the vulnerability of the healthcare industry and the continued ransomware attacks on the organizations that provide medical care, Beek says.

He warns that the trend will likely continue, given the anemic funding for cybersecurity in healthcare.

"This is not just the a ransomware perspective — it's also about the level of vulnerability," he says. "For me, that is a concern. You want to go to a hospital to get treated, and you don't want delays because of ransomware."

Ransomware Attempts Flag as Payments Also Decline

How a well-meaning employee could unwittingly share their identity with other users, causing a whole range of problems across IT, security, and the business.

Last month I wrote an article about the way low-code/no-code platforms are offering credential-sharing as a service, why they are doing it, and how this looks from an attacker's perspective. In this article, I'll focus on the implications of that compromise and how it affects enterprises today.

Here's why sharing your enterprise credentials with somebody else is bad practice. Say I want to pass my credentials to a colleague in order to query production logs for some one-off user-behavior analysis. In a typical enterprise, granting someone permissions to query a new data source could mean a long access review process, especially when it comes to production or sensitive data. My colleague could easily get frustrated. "All I wanted is to do this tiny one-off query, and I've already been waiting for a month!" they could say. I could just run the query for them, but I'm swamped with my own day-to-day tasks, and one-off queries tend to get complicated.

I am left with one quick solution: I could just share my username/password with my colleague. If they get an MFA challenge, I'll gladly approve. I don't have to spend the time running the query, and my colleague gets unblocked. Everybody wins! Right?

Well, you would be right in your analysis, but you are missing the bigger picture. While it's important for the enterprise that your colleague gets their user behavior analysis done, it is equally, if not more, important that your enterprise remains compliant with a whole host of privacy and security standards and maintains customer trust by upkeeping the company's commitment to security.

If high-level enterprise goals do not convince you, consider the central management teams in IT or security. Those teams base their operations and security strategies on the fact that each user has their own unique identity. IT teams are setting up networking and access policies that assume each user would be logged in from one corporate IP or corporate laptop at once; security teams are correlating events based on user ID; finance teams could be aggregating cost reports per user and their personal cloud environment. Credential sharing undermines all of those assumptions, among others. It strips away the basic meaning of an online identity.

**A Real-World Example**

Let's turn to the world of low-code/no-code and examine a real-world scenario. In a large enterprise, Jane, an inspired employee from the customer care team, realized that when employees across the organization take part in a customer case, they are usually missing key information about the customer, such as their support case history and latest purchases. This degrades the customer's experience, since they have to explain their issue again and again while the case gets routed to the right employee who can address the issue.

To improve this, Jane created an app that allows company employees to view this key information about customers when those employees are part of the team responsible for addressing the customer's support case. First, let's take a moment to acknowledge the power of low-code/no-code, which allows Jane to identify a need and address it on her own, without asking for a budget or waiting for IT resource allocations.

While building the application, Jane had to work around multiple issues, the biggest one being permissions. Employees across the organization don't have direct access to query the customer database to get the information they need. If they did, then Jane wouldn't have to build this application. To overcome this issue, Jane logged into the database and embedded her authenticated session directly in the application. When the application receives a request from one user, it will use Jane's identity to execute that query and then return the results to the user. This credential-embedding feature, as we explored last month, is a key feature of low-code/no-code platforms. Jane made sure to set up role-based access control (RBAC) in the application such that every user can only access customer cases they are assigned to.

The application solved an important business problem, and so it quickly gained user adoption across the enterprise. People were happy that they could provide better service to their customers by having the right context for the conversation. Customers were happy, too. A month after Jane created the application, it was already used by hundreds of users across the organization, with customer satisfaction rates rising.

Meanwhile at the SOC, a high-severity alert showing abnormal activity around the production customer database was triggered and assigned to Amy, an experienced security analyst. Amy's initial investigation showed an internal user was trying to scrape the entire database, querying information about multiple customers from multiple IP addresses across the organization. The query pattern was very complex; instead of a simple enumeration pattern you would expect to see when a database is being scraped, the same customer's data was queried multiple times, sometimes through different IP addresses and on different dates. Could this be an attacker trying to confuse the security monitoring systems?

After a quick investigation, Amy uncovered a crucial piece of information: All of those queries across all IP addresses and dates were using a single user identity, someone named Jane from the customer care team.

Amy reached out to Jane to ask her what's going on. At first, Jane didn't know. Were her credentials stolen? Did she click on the wrong link or trust the wrong incoming email? But when Jane told Amy about the application she recently built, they both realized there might be a connection. Amy, the SOC analyst, wasn't familiar with low-code/no-code, so they reached out to the AppSec team. With Jane's help, the team figured out that Jane's application had Jane's credentials embedded within it. From the database's perspective, there was no application — there was just Jane, executing a whole lot of queries.

Jane, Amy, and the AppSec team decided to shut down the application until a solution was found. Application users across the organization were frustrated since they had come to rely on it, and customers were feeling it, too.

While Amy closed the issue and documented their findings, the VP of customer care was not happy seeing customer satisfaction rate drop, so they asked Jane to look for a permanent solution. With the help of the platform's documentation and the organization's Center of Excellence team, Jane removed her embedded identity from the application, changed the app to use each user's identity to query the database, and ensured users gain permissions only to customer cases they are associated with. In its new and improved version, the application used each user's identity to query the customer database. Jane and the application users were happy that the application is back online, Amy and the AppSec team were happy that Jane's identity is no longer shared, and the enterprise saw customer satisfaction rate starting to climb up again. All was well.

Two weeks later, the SOC received another alert on abnormal access to the production customer database. It looked suspiciously similar to the previous alert on that same database. Again, IP addresses from across the organization were using a single user's identity to query the database. Again, that user was Jane. But this time, the security team and Jane knew that the app uses its user's identities. What's going on?

The investigation revealed that the original app had implicitly shared Jane's authenticated database session with the app's users. By sharing the app with a user, that user got direct access to the _connection_, a wrapper around an authenticated database session provided by the low-code/no-code's platform. Using that connection, users could leverage the authenticated session directly — they no longer had to go through the app. It turns out that several users had found this out and, thinking that this was the intended behavior, were using Jane's authenticated database session to run their queries. They loved this solution, since using the connection directly gave them full access to the database, not just for customer cases that they are assigned to.

The connection was deleted, and the incident was over. The SOC analyst reached out to users who had used Jane's connection to ensure they discarded any customer data they have stored.

**Addressing the Low-Code/No-Code Security Challenge**

The story above is a real-life scenario from a multinational B2C company. Some details were omitted or adjusted to protect privacy. We've seen how a well-meaning employee could unwittingly share their identity with other users, causing a whole range of problems across IT, security, and the business. As we explored last month, credential-sharing is a key feature of low-code/no-code. It's the norm, not the exception.

As low-code/no-code continues to bloom in the enterprise, consciously or not, it is crucial for security and IT teams to join the business development conversation. Low-code/no-code apps come with a unique set of security challenges, and their prolific nature means those challenges become acute faster than ever before.

Watch Out for User Impersonation in Low-Code/No-Code Apps

AI's potential for automating security has promise, but there are miles to go in establishing decision-making boundaries.

Would you let a child drive a car? I imagine that most people would think that is reckless and dangerous. However, what if the car were affixed to guardrails that limited its movement so that it can only move within certain bounds inside an amusement park?  

Allowing the current generation of artificial intelligence (AI) technologies to make decisions and take actions on our behalf is like having a 5-year-old take a car out for a joyride, but without the appropriate guardrails to prevent a terrible accident or an incident with potentially irreversible consequences.

Security professionals are often led to believe that AI, machine learning, and automation will revolutionize our security practices and allow us to automate security, perhaps even achieve a state of "autonomic security." But what does that really mean and what unintended consequences might we encounter? What guardrails should we consider that are commensurate with the "age" of AI?

To understand what we are getting ourselves into and the appropriate guardrails for security use cases, let us consider the following three questions.

*   How do AI/ML, decision-making, and automation relate to one another?
*   How mature are our AI/ML and automated decision-making capabilities?
*   How mature do they need to be for security?

To answer each of these questions, we can examine a combination of three frameworks: the OODA loop, DARPA's Three Waves of AI, and Classical Education.

**OODA Loop  
**The OODA loop stands for Observe, Orient, Decide, Act, but let's use a slightly modified version:

*   Sensing
*   Sense-making
*   Decision-making
*   Acting

Within this framework, AI/ML (sense-making) is distinct from automation (acting) and connected by a decision-making function. Autonomic means involuntary or unconscious. In the context of this framework, autonomic could mean either skipping sense-making and decision-making (e.g., involuntary stimulus-response reflexes) or skipping just decision-making (e.g., unconscious breathing). In either case, something that is autonomic skips decision-making.

**DARPA's Three Waves of AI  
**DARPA's framework defines the advancement of AI through several waves (describe, categorize, and explain). The first wave takes handcrafted knowledge of experts and codifies it into software to provide deterministic outcomes. The second wave involves statistical learning systems, enabling pattern recognition and self-driving cars. This wave produces results that are statistically impressive but also individually unreliable.

For the errant results, these systems have minimal reasoning capabilities and thus they cannot explain why it produces incorrect results from its sense-making. At DARPA's third wave, AI is able to provide explanatory models that enable us to understand how and why any sense-making mistakes are made. This understanding helps increase our trust in its sense-making capabilities.

According to DARPA, we haven't reached this third wave yet. Current ML capabilities can give us answers that are often correct, but they're not mature enough to tell us how or why they arrived at their answers when they're incorrect. Mistakes in security systems leveraging AI can have consequential outcomes, so root cause analysis is critically important to understand the reason behind these failures. However, we do not get any explanation of the "how" and "why" with results produced by the second wave.

**Classical Education  
**Our third framework is the Classical Education Trivium, which describes three learning stages in child development. At the elementary school stage, children focus on memorizing facts and learning about structures and rules. At the dialectic stage in middle school, they focus on connecting related topics and explaining how and why. Finally, in the rhetoric stage of high school, students integrate subjects, reason logically, and persuade others.

If we expect children to be able to explain how and why at middle school (somewhere around the ages of 10 to 13), that suggests that the current generation of AI, which lacks the ability to explain, isn't past the elementary stage! It has the cognitive maturity of a child that is less than 10 years old (and some suggest significantly younger.)  

With autonomic security, we're skipping decision-making. But if we were to have the current generation of AI do the decision-making for us, we must recognize that we're dealing with a system that has the decision-making capacity of an immature child. Are we ready to let these systems make decisions on our behalf without proper guardrails?

**Need for Guardrails  
**The march toward automated and autonomic security will undoubtedly continue. However, with some guardrails, we can minimize the carnage that would otherwise ensue. Here are points for consideration:

*   **Sensor diversity**: Ensure sensor sources are trustworthy and reliable, based on multiple sources of truth.
*   **Bounded conditions**: Ensure decisions are highly deterministic and narrowly scoped.
*   **Established thresholds**: Know when the negative repercussions of action might exceed the costs of inaction when something goes wrong.
*   **Algorithmic integrity**: Ensure that the entire process and all assumptions are well-documented and understood by the operators.
*   **Brakes and reverse gear**: Have a kill switch ready if it goes beyond the scope and make the action immediately reversible.
*   **Authorities and accountabilities**: Have pre-established authorities for taking action and accountabilities for outcomes.

Allowing a child to drive a car without proper guardrails would be irresponsible. Let's make sure that we have well thought-out guardrails for AI-driven security before we let our immature machines take the wheel.

Building Guardrails for Autonomic Security

IT asset tracker and auditor software has a critical issue with insecure object deserialization that could allow threat actors to execute code, researchers say.

_Editor's note: Update at bottom of story._

Netwrix IT asset tracker and compliance auditor, used across more than 11,500 organizations, contains a critical Insecure Object Deserialization vulnerability that could lead to Active Directory domain compromise, a new advisory warns. 

The CVE is pending, according to Bishop Fox, which just released details of the vulnerability, which affects all older supported versions of the Netwrix application versions, back to 9.96. 

Organizations should immediately update their Netwrix applications to the latest version, 10.5, released on June 6, to protect their systems, the researchers urge.

The bug was discovered by an nmap TCP port scan of a Netwrix Auditor server, the Bishop Fox alert says. "The Netwrix Auditor application is affected by an insecure object deserialization issue that allows an attacker to execute arbitrary code with the privileges of the affected service," the Bishop Fox team says.  "In a typical real-world scenario, Netwrix Auditor services would be running with a highly privileged account, which could lead to full compromise of the Active Directory environment."

UPDATE, July 18:

“Upon receiving the vulnerability report from Jordan Parkin of Bishop Fox, the Netwrix development team worked diligently to remediate it. On June 6, 2022, Netwrix released Netwrix Auditor 10.5 which included a fix for this vulnerability, and published a security advisory to its customers advising them of the risk and the need to upgrade. Netwrix thanks Mr. Parkin for his collaboration and coordinated disclosure of this vulnerability. Customers requiring assistance deploying Netwrix Auditor 10.5 should contact the support team via the customer web portal or by phone in the US at +1.888.638.9749.”

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

Netwrix Auditor Bug Could Lead to Active Directory Domain Compromise

As more employees plan on taking longer holidays and working remotely from the destination for part of that time, organizations have to consider the risks. Like Wi-Fi networks.

_Many employees are requesting a "hybrid holiday" — where longer holidays are booked with the intention of spending time working remotely from the travel destination. In a Virgin Media O2 survey from earlier this year, 76% of workers polled said they were considering adding remote-work days around their annual leave to extend their time away._

**Question: What are the risks of employees going on a hybrid holiday?**

**John Ayers, Interim CISO and Vice President of Product, Advanced Detection, & Response at Optiv:** Threat actors are like any other criminals — they do reconnaissance, and social media has become the best recon tool in the trade craft. With employees now looking to combine work with holiday plans, this has only increased the security risks for users and their companies.

Let's take an example of going overseas to Rome. It's a nice place to visit, but you also need to work. First, Internet is not a "like for like," meaning the type of access you would have there is not like yours at home. Yes, we all have been led to believe coffee shop and hotel Wi-Fi is OK to use since COVID — but it is not.

Second, not all locations are friendly. Most companies should be deploying, or have already deployed, geo-blocking in order to prevent employees from connecting in countries or locations with high risk or out of the US. Geo-blocking is a great tool to prevent and deny all access from a region. Most CISOs today need to protect access to data, which means denying access from devices based on location. They are trying to prevent MitM (man-in-the-middle attack). Why is that important? MitM employs someone setting up an access point that might not be what you think it is.

Each time you fire up the laptop or mobile device and log into Amazon or your work email, you are practicing what we call "data in motion" using the rogue Wi-Fi connection, which is now collecting all that data.

The risks here are:

*   **Location.** You now are advertising where you are.
*   **Browsing history.**
*   **Purchasing.** Yes, the credit card you used was just compromised. How do you avoid that? Tether your device and get an Internet plan with a secure option. I have used TEP Wireless because it grants me access wherever I go using an always-on VPN. Check with your company about traveling — especially out of the country.

So, the next time you try to take vacation and look to access your company's email and OneDrive, remember this: Using public Wi-Fi is like buying sushi at a gas station — you never know how sick you will get until you consume it.

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

What Are the Risks of Employees Going on a 'Hybrid Holiday'?

Developers need to be cautious about whom they trust on GitHub because it's easy to establish fake credibility on the platform, security vendor warns.

The metadata that developers look at when deciding whether to use an open source project on GitHub can be easily forged and gives attackers a way to trick users of the platform into downloading malicious code.

Developers therefore need to be diligent about verifying the identity of those committing code to the repository and not take the metadata at face value, researchers at Checkmarx warn in a new report.

Developers looking for an open source project on GitHub tend to favor those that are active, maintained, and are associated with developers that have an established track record on the platform. Among the data points that developers consider are the number of commits — or changes — that a contributor of open source code to GitHub might have made to a project over time. Git assigns a unique ID to each change that describes the specific change that was made, who created the change, and a timestamp for it. Generally, a project with a lot of commits associated with it is perceived as a sign that it is being actively maintained.

But an attacker can easily fake or forge all these data points to lend an appearance of credibility to their code and fool unwary developers into downloading malicious code, according to Checkmarx.

For example, the timestamp associated with each commit can be manipulated to make it appear like a change happened at a very different time than it did. All a threat actor has to do to pull that off is to alter two variables on their local machine, according to the report.

**Easy to Establish Fake Credibility**

A malicious actor who creates a brand-new account on GitHub can fabricate numerous commits with timestamps that go back over years to make it appear they have been active on the platform or a long time. "A prominent measure for a user activity on GitHub is the 'activity graph' presented on the user's profile page," Checkmarx's report says. "This graph is essentially a heatmap showing the user's activity through time. Hence, if we are able to fabricate commits with any timestamp we want, we can fill this graph with falsified activities."

Similarly, an attacker can push a poisoned commit to a GitHub repository by spoofing the identity of a trusted contributor. The attacker would just need to find out the trusted user's email address and then set the username and email address on the Git command line and commit changes. Though GitHub offers ways for developers to hide their email address, most do not use these features, making it possible for attackers to find it relatively easily, the report says.

The ability to spoof a user's account makes it possible for an attacker to populate their own project's contributor's section with the identities of other trusted individuals. This can fool developers into thinking the attacker's project is trustworthy and reliable, the security vendor says. 

What makes this tactic alarming is the fact that the user being spoofed does not get any notification about their account being added as a contributor to another project.

Tzachi Zornstain, head of supply chain security at Checkmarx, says that to mitigate the risk of being fooled, developers should check if the code they plan on use was submitted by someone whose identity has been verified. GitHub offers a feature that allows developers to verify their identities when committing code. 

"A developer can go and check if the commits that he is seeing are 'verified commits' or not, and based on that decide if he wants to trust those developers," Zornstain says. "If a project claims to have multiple contributors commit code \[make sure\] those commits are verified also."

He also recommends that developers use a GitHub feature that allows them to digitally sign their code, so their contribution is verified as their own. The feature includes a "vigilant mode" that displays the status of all code contributed under the name, including ones that others might submit under their name, GitHub also has noted that all developers who contribute code will need to turn on two-factor authentication by 2023 if they want to be able to continue doing so.

Checkmarx will also be releasing an open source tool soon that will help developers easily distinguish between commits and unverified commits to public projects so they cannot be easily tricked, he says. "If the way GitHub presents developer activity and contribution to projects would be based on verified commits," he says, "that would help drive the adoption of verified commits and won’t allow attackers to easily fool developers."

Source

DARKReading