A trio of security bugs allow remote attackers to unlock or start the car, operate climate controls, pop the trunk, and more — all via poorly coded mobile apps.

At least three mobile apps tailored to allow drivers to remotely start or unlock their vehicles were found to have security vulnerabilities that could allow unauthenticated malicious types to do the same from afar. Researchers say securing APIs for these types of powerful apps is the next phase in preventing connected car hacking.

According to Yuga Labs, car-specific apps from Hyundai and Genesis, as well as the SiriusXM smart vehicle platform (used by various automakers, including Acura, Honda, Nissan, Toyota and others), could have allowed attackers to intercept traffic between the apps and vehicles made after 2012.

**Hyundai Apps Allow Remote Car Control**

When it comes to the MyHyundai and MyGenesis apps, an investigation of the API calls that the apps make showed that owner validation is done through matching up the driver's email address with various registration parameters. After playing around with potential ways to subvert this "pre-flight check," as the researchers called it, they discovered an avenue of attack:

"By adding a CRLF character at the end of an already existing victim email address during registration, we could create an account which bypassed the ... email parameter comparison check," they explained in a series of tweets detailing the weaknesses. From there, they were able to gain complete control over the apps' commands — and over the car. In addition to starting the car, attackers could set the horn off, control the AC, and pop the trunk, among other things.

They were also able to automate the attack. "We took all of the requests necessary to exploit this and put it into a python script which only needed the victim's email address," they tweeted. "After inputting this, you could then execute all commands on the vehicle and takeover the actual account."

"Many car hacking scenarios are the result of an API security issue, not an issue with the mobile app itself," Scott Gerlach, co-founder and CSO at StackHawk, says. "All of the sensitive data and functions of a mobile app reside in the API an app talks to, so that's what needs to be secure. The upside is this is a very targeted type of attack and would be difficult to mass execute. The downside is it's still highly invasive for the targeted car owner."

The finding showcases the criticality of API security testing, Gerlach says.

"Testing APIs for OWASPs Top 10 vulnerabilities including Insecure Direct Object Access and Broken Function Authorization is no longer a nice-to-have step in the software development lifecycle," he notes. "In the way connected cars are sold today ... is similar to a customer opening a bank account and then being tasked to create their online access based on the account number alone. Anyone could find that data with little effort and put your assets at risk because the verification process was not thought through."

**SiriusXM-Based Car Hacking**

While most people know SiriusXM as a satellite radio juggernaut, the company is also a connected vehicle telemetry provider, providing 12 million connected cars with functions like remote start, GPS location, remote climate controls, and more. A wide range of automakers, including Acura, BMW, Honda, Hyundai, Infiniti, Jaguar, Land Rover, Lexus, Nissan, Subaru, and Toyota, all use the SiriusXM connected car platform, according to its website.

The Yuga researchers examined one of the mobile apps that SiriusXM powers, the NissanConnect app, and found that if they knew a target's vehicle identification number (VIN, which is visible through most cars' front windshields), they could send forged HTTP requests to the endpoint and get back a host of information, including a driver's name, phone number, address, and vehicle details that could be used to execute remote commands on the car through the app.

From there, they built another automated script. "We made a simple Python script to fetch the customer details of any VIN number," they said in a tweet thread.

"This latest vulnerability isn’t about embedded systems or the manufacturing, but rather the web application itself," Connor Ivens, competitive intelligence manager for security at Tanium, tells Dark Reading. "Researchers are using the car VIN numbers as the primary key of customer ID, and sending POST requests to generate a bearer token. This allows you administrative control to issue other requests over the car."

It's clear that mobile app security needs to be hardened. "The app service itself is almost an afterthought of the purchase process," Gerlach says. "Car manufacturers need to think more deeply about how to better integrate the connected service into the purchase and validation process for the customer."

**Expect to Crash Into Car Security Vulnerabilities**

Yuga disclosed the flaws to both Hyundai and SiriusXM, which promptly issued patches. No real-world attacks occurred, but researchers tell Dark Reading that these kinds of bug discoveries will continue to come to the fore, especially as vehicles become more connected, and the complexity of onboard software and remote capabilities goes up.

While connected and autonomous vehicles have an expanded attack surface similar to enterprise environments, impacted consumers don’t have an entire cybersecurity team working for them, says Karen Walsh, cybersecurity compliance expert and CEO at Allegro Solutions. Thus, the onus is on carmakers to do better.

"Whether the industry likes it or not, it’s going to need to work harder to secure this attack vector. This will also place a much larger burden on the industry from a supply chain standpoint. It’s not just the vehicles that need to be secured, but all the additional technologies — in this case infotainment like SiriusXM — that need to be included in any security initiative."

**Evolving Past the Jeep Hacking Demo**

We may see an uptick in probing for such flaws as well. Since the infamous 2015/2016 Jeep hacking demos from Charlie Miller and Chris Valasek at Black Hat USA brought potential physical vulnerabilities in connected cars to light, the field of automotive hacking has exploded.

"The Jeep hacking demo involved hacking over cellular modems (and cell companies disabled some key functionality as a result)," says John Bambenek, principal threat hunter at Netenrich. "Web apps have their own security concerns distinct from that path of communication. I don't have to own the entire communication stack, I just need to find a soft spot and researchers continue to find them. The reality is that it's all put together with defective duct tape and bailing wire ... it always has been."

Mike Parkin, senior technical engineer at Vulcan Cyber, says that mobile is the next frontier.

"It was challenging enough when threat actors were just attacking key fobs with remote range and limited capability," he tells Dark Reading. "Now, with cars being as much a mobile computing platform as a vehicle, it will only get more challenging."

He adds, "If an attacker can compromise a mobile device, they could potentially control many of the applications on it including a user’s vehicle control app. The control channels between a user's mobile device, the manufacturer’s cloud services, and the vehicle itself are another attack surface threat actors could leverage."

SiriusXM, MyHyundai Car Apps Showcase Next-Gen Car Hacking

Journalists in El Salvador haul NSO Group to US court for illegal surveillance that ultimately compromised their safety.

Nearly two dozen journalists and other staffers working for El Faro, a digital newspaper based in El Salvador, are suing NSO Group for unleashing Pegasus spyware — malware they say was used to steal their most sensitive information, putting their safety in danger.

Along with ASO Group Technologies, its Israeli parent company, Q Cyber Technologies is also named as a defendant in the lawsuit.

The 22 plaintiffs from El Faro are getting an assist from the Knight First Amendment Institute at Columbia University in their litigation. Attorneys for the El Faro group say that because Apple servers in Silicon Valley were compromised by Pegasus to monitor the newsroom, they have filed the lawsuit in the US District Court in Northern California.

Pegasus spyware has a long history of being used by authoritarian governments to essentially take full control of devices of those they deem likely to stoke dissent. Once Pegasus is deployed, the complaint explains, the threat actor has control of the entire device, from downloading contacts and text messages to turning on the device microphone to listen to conversations in real time.

"They can activate the smartphone's camera to take photographs," the complaint added. "They can also copy authentication keys to gain access to cloud-based accounts."

Members of the news-gathering group at the influential Central American outlet claim they were targeted by the Salvadoran government while working on stories about human rights abuses and communicating with confidential sources, including the US Embassy, according to the court filing.

"The Pegasus attacks have profoundly disrupted Plaintiffs' lives and work," the Pegasus spyware suit claims. "The attacks have compromised Plaintiffs' safety as well as the safety of their colleagues, sources, and family members."

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

Newsroom Sues NSO Group for Pegasus Spyware Compromise

Following a year of increasingly disruptive attacks, advanced persistent threat groups will likely only become emboldened in 2023, security experts say.

In November, Ukraine's president revealed that the country's IT defenses fended off more than 1,300 Russian cyberattacks, including attacks on satellite communications infrastructure.

The onslaught of cyberattacks highlights one of the shifts in advanced persistent threat (APT) attacks seen in the past year: In 2022, geopolitical tensions ratcheted up, and along with them, cyber operations became the go-to strategy for national governments. While Russia and other nations have used cyberattacks to support military actions in the past, the ongoing war represents the most sustained cyber operation to date and one that will undoubtedly continue in the coming year, experts say.

Military conflict will join cybercrime as a driving force behind APT groups in the coming year, John Lambert, corporate vice president and distinguished engineer at Microsoft's Threat Intelligence Center, stated in the company's Digital Defense Report 2022 released last month.

"The conflict in Ukraine has provided an all-too-poignant example of how cyberattacks evolve to impact the world in parallel with military conflict on the ground," he said. "Power systems, telecommunication systems, media, and other critical infrastructure all became targets of both physical attacks and cyberattacks."

While the increased use of APT attacks by Russia is the most visible change that occurred in the past year, APTs are evolving. More are moving onto critical infrastructure, adopting dual-use tools and living-off-the-land techniques, and pinpointing the software supply chain to gain access to targeted companies.

Cybercriminals are using increasingly sophisticated tools, but APT techniques are typically attributed to nation-state operations, meaning that companies need to become more aware of the techniques used by advanced actors and how they may be motivated by geopolitical concerns, says Adam Meyers, senior vice president of intelligence for cybersecurity services firm CrowdStrike.

"You don't have one uniform threat — it changes by business vertical and geo-location," he says. "You — and this has been our mantra for many years — don't have a malware problem, you have an adversary problem, and if you think about who those adversaries are, what they are after, and how they operate, then you will be in a much better position to defend against them."

**Critical Infrastructure, Satellites Increasingly Targeted**

In 2021, the attack on oil-and-gas distributor Colonial Pipeline highlighted the impact that cybersecurity weakness could have on the US economy. Similarly, this year's attack on the Viasat satellite communication system — likely by Russia — showed that APT threat actors have continued to focus on disrupting critical infrastructure through cyberattacks. The trend has gained momentum over the past year, with Microsoft warning that the number of nation-state notifications (NSNs) the company issued as alerts to customers more than doubled, with 40% of the attacks targeting critical infrastructure, compared to 20% in the prior year.

Critical infrastructure is not just a target of nation-state actors. Cybercriminals focused on ransomware are also targeting critical infrastructure companies, as well as pursuing a hack-and-leak strategy, Kaspersky stated in its recently published APT predictions.

"We believe that in 2023 we will see a record number of disruptive and destructive cyberattacks, affecting government, industry, and critical civilian infrastructure — perhaps energy grids or public broadcasting, for instance," says David Emm, principal security researcher at Kaspersky. "This year, it became clear just how vulnerable physical infrastructure can be, so it's possible we might see targeting of underwater cables and fibre distribution hubs."

**Not Just Cobalt Strike**

Cobalt Strike has become a popular tool among APT groups, because it provides attackers — and when used for its legitimate purposes, red teams and penetration testers — post-exploitation capabilities, covert communications channels, and the ability to collaborate. The red-team tool has "crop\[ped\] up in a myriad of campaigns from state-sponsored APTs to politically motivated threat groups," says Leandro Velasco, a security researcher with cybersecurity firm Trellix.

Yet, as defenders have increasingly focused on detecting both Cobalt Strike and the popular Metasploit Framework, threat actors have moved toward alternatives, including the commercial attack simulation tool Brute Ratel C4 and the open source tool Sliver.

"Brute Ratel C4 ... is especially dangerous since it has been designed to avoid detection by antivirus and EDR protection," Kaspersky's Emm says. Other up-and-coming tools include Manjusaka, which has implants written in Rust for both Windows and Linux, and Ninja, a remote exploitation and control package for post exploitation, he says.

**Identity Under Attack**

Following the coronavirus pandemic, remote work — and the cloud services to support such work — have increased in importance, leading attackers to target those services with identity attacks. Microsoft, for example, saw 921 attacks every second, a 74% increase in volume over the past year, the company stated in its report.

In fact, identity has become a critical component to securing the infrastructure and enterprise, while at the same time becoming a major target of APT groups. Every breach and compromise investigated by CrowdStrike in the past year has had an identity component, CrowdStrike's Meyers says.

"We used to say trust, but verify, but the new mantra is verify and then trust," he says. "These attackers have started targeting that soft underbelly of identity ... that is a complex part of the system."

**IT Supply Chains Under Attack**

The attack on SolarWinds and the widely exploited vulnerability in Log4J2 demonstrated the opportunities that vulnerabilities in the software supply offer to attackers, and companies should expect APT groups to create their own vulnerabilities through attacks on the software supply chain.

While there has been no major event yet, attackers have targeted Python ecosystems with dependency confusion attacks against open source repositories and phishing attacks targeting Python developers. Overall, the number of attacks targeting developers and companies increased by more than 650% over the past year.

In addition, APT actors are finding the weak points in vendor and supplier relationships and exploiting them. In January, for example, the Iran-linked DEV-0198 group compromised an Israeli cloud provider by using a compromised credential from a third-party logistics company, according to Microsoft's report.

"This past year of activity demonstrates that threat actors ... are getting to know the landscape of an organization's trusted relationships better than the organizations themselves," the report stated. "This increased threat emphasizes the need for organizations to understand and harden the borders and entry points of their digital estates."

To harden their defenses against APT groups and advanced attacks, companies should regularly verify their cybersecurity hygiene, develop and deploy incident response strategies, and integrate actionable threat intelligence feeds into their processes, says Trellix's Velasco. To make identity attacks more difficult, multifactor authentication should be routine, he says.

"In 2023, simple security planning is not enough to deter or prevent attackers," Velasco says. "System defenders need to implement a more proactive defensive approach."

Where Advanced Cyberttackers Are Heading Next: Disruptive Hits, New Tech

A do-it-yourself machine-learning system helped a French bank detect three types of exfiltration attacks missed by current rules-based systems, attendees will learn at Black Hat Europe.

Using an internally developed machine-learning model trained on log data, the information security team for a French bank found it could detect three new types of data exfiltration that rules-based security appliances did not catch.

Carole Boijaud, a cybersecurity engineer with Credit Agricole Group Infrastructure Platform (CA-GIP), will take the stage at next week's Black Hat Europe 2022 conference to detail the research into the technique, in a session entitled, "Thresholds Are for Old Threats: Demystifying AI and Machine Learning to Enhance SOC Detection." The team took daily summary data from log files, extracted interesting features from the data, and used that to find anomalies in the bank's Web traffic. 

The research focused on how to better detect data exfiltration by attackers, and resulted in identification of attacks that the company's previous system failed to detect, she says.  

"We implemented our own simulation of threats, of what we wanted to see, so we were able to see what could identify in our own traffic," she says. "When we didn't detect \[a specific threat\], we tried to figure out what is different, and we tried to understand what was going on."

As machine learning has become a buzzword in the cybersecurity industry, some companies and academic researchers are still making headway in experimenting with their own data to find threats that might otherwise hide in the noise. Microsoft, for example, used data collected from the telemetry of 400,000 customers to identify specific attack groups and, using those classifications, predict future actions of the attackers. Other firms are using machine-learning techniques, such as genetic algorithms, to help detect accounts on cloud computing platforms that have too many permissions.

There are a variety of benefits from analyzing your own data with a homegrown system, says Boijaud. Security operation centers (SOCs) gain a better understanding of their network traffic and user activity, and security analysts can gain more insight into the threats attacking their systems. While Credit Agricole has its own platform group to manage infrastructure, handle security, and conduct research, even smaller enterprises can benefit from applying machine learning and data analysis, Boijaud says.

"Developing your own model is not that expensive and I'm convinced that everyone can do it," she says. "If you have access to the data, and you have people who know the logs, they can create their own pipeline, at least in the beginning."

**Finding the Right Data Points to Monitor**

The cybersecurity engineering team used a data-analysis technique known as clustering to identify the most important features to track in their analysis. Among the features that were deemed most significant included the popularity of domains, the number of times systems reached out to specific domains, and whether the request used an IP address or a standard domain name.

"Based on the representation of the data and the fact that we have been monitoring the daily behavior of the machines, we have been able to identify those features," says Boijaud. "Machine learning is about mathematics and models, but one of the important facts is how you choose to represent the data and that requires understanding the data and that means we need people, like cybersecurity engineers, who understand this field."

After selecting the features that are most significant in classifications, the team used a technique known as "isolation forest" to find the outliers in the data. The isolation forest algorithm organizes data into several logical trees based on their values, and then analyzes the trees to determine the characteristics of outliers. The approach scales easily to handle a large number of features and is relatively light, processing-wise.

The initial efforts resulted in the model learning to detect three types of exfiltration attacks that the company would not otherwise have detected with existing security appliances. Overall, about half the exfiltration attacks could be detected with a low false-positive rate, Boijaud says.

**Not All Network Anomalies Are Malicious**

The engineers also had to find ways to determine what anomalies indicated malicious attacks and what may be nonhuman — but benign — traffic. Advertising tags and requests sent to third-party tracking servers were also caught by the system, as they tend to match the definitions of anomalies, but could be filtered out of the final results.

Automating the initial analysis of security events can help companies more quickly triage and identify potential attacks. By doing the research themselves, security teams gain additional insight into their data and can more easily determine what is an attack and what may be benign, Boijaud says.

CCA-GIP plans to expand the analysis approach to use cases beyond detecting exfiltration using Web attacks, she says.

SOC Turns to Homegrown Machine Learning to Catch Cyber-Intruders

Rather than regarding risk assessment as a negative exercise, consider it one that benefits your organization's aims, and then translate the risk level to its impact on operations, reputation, or finances.

The risk assessment methodology is a foundational pillar of effective information security and there are numerous risk methodologies available to allow organizations to identify, quantify, and mitigate information security risks to its information assets. But, as we all know, risk is subjective.

Personal experience, subject knowledge, and anecdotal sources can all result in mixed results. How we make sense of the risks to information and present this information in a meaningful way is where risk assessment comes in, enabling the business to identify risks, determine potential impacts, and to analyze those risks to determine the risk level, appropriate controls, and to calculate a risk rating.

Determining the right risk assessment methodologies for your business will depend upon several factors. These can include the industry the business operates in, its size and scope, and the compliance regulations to which it's subject.

**The Right Fit**

Unless specified contractually, the risk methodology should fit the business, not the other way around. A clear understanding of the risks faced in the collection, processing, storing, sharing, and disposal of information is key to ensuring that those risks are managed appropriately to the impact of a breach, whether to its own or customer data.

You'll also need to decide whether you are looking for a qualitative or quantitative approach or a combination of both methods, and what you're trying to achieve, i.e., the risks you wish to mitigate and where. Are you looking to address threats and vulnerabilities; protect personal information, data sets, or business-critical information; or reduce the risk posed to the services of the business, its physical hardware, or staff?

Component-driven risk focuses on technical components and the threats and vulnerabilities they face, so looks at individual elements. System-driven risk, on the other hand, analyzes systems or processes as a whole, so takes more of an overview. Although different, they are deemed complementary. Most organizations adopt the component methodology, which requires the organization to identify specific information assets and its associated risks to its confidentiality, integrity, and availability (aka, CIA).

The CIA triad enables the security team to keep data secure while ensuring legitimate access to data. It is essential to use alongside your risk framework, as it can help control the risk to data associated with the introduction of new systems or devices, for instance.

Given all these variables, there are, of course, numerous frameworks to choose from. Some of the most well-known are ISO 27005:2011, ISF IRAM2, NIST (SP800-30), Octave Allegro, and ISACA COBIT 5 for risk, for example. There's no one-size-fits-all approach, and all have their strengths and weaknesses, leading many teams to adopt more than one approach.

**Pitfalls to Avoid

Risk methodologies will only ever be as good as the data we put into them. This means it's relatively common for teams to be too restrictive in their scope and to overlook assets. All too often, we've seen examples of asset lists that only contain IT assets, without including information assets, for instance. An information asset has its own value, which doesn't change whether it is in physical, electronic, or tacit form, but excluding this from the organization's asset list would skew results.

Another common failing is to restrict the way risk assessment is used. It's often regarded as a negative exercise because it sees the enforcement of controls, so it's important to counter this by ensuring the assessment benefits the aims of the organization and doesn't hinder or stifle its success.

Understanding what lies behind the risk is also key, i.e., the threats/vulnerabilities and their likelihood of realization — and this needs to be translated in a meaningful way.

Risk assessment can lead to risk registers producing risk matrices and red-amber-green (RAG) status indicators without conveying the relative impact in a business language. Being able to effectively communicate risk to those responsible for managing the purse strings is vital to securing funds for risk protection. For example, describing a risk as red, or 43, will mean very little to most laypeople, whereas a description of the impact to operations, reputation, finances, or punitive measures will see the issues described using business language that will be readily understood by senior management. Indeed, the importance of being able to translate risk into meaningful business impacts is an often underappreciated skill.

The output of risk assessments should guide the business to invest in the controls that best meet its objectives. They should also, just as importantly, highlight when spending on new technology or controls does not contribute to those goals.

Finally, it's important that the applied risk methodology creates an environment where consistent, repeatable results are produced. This will help the business evaluate whether risks have increased, whether existing controls are adequate, and where exposure has increased, leading to a more accurate risk profile and clearer understanding of the overall security risk posture.

**

A Risky Business: Choosing the Right Methodology

Amazon Security Lake will allow organizations to create a purpose-built, standards-based data lake to aggregate and store security data.

Amazon Web Services unveiled the Amazon Security Lake, a standards-based data lake for security data, at this week's AWS re:Invent 2022 conference. The new cybersecurity service will allow organizations to aggregate logs and event data from multiple sources and analyze them to quickly detect and respond to threats.

Security data is usually scattered across an organization's environment, as applications, firewalls, and identity providers maintain their own logs and event data. They are also often in disparate data formats, making it difficult for security teams to aggregate them. Creating processes to normalize data across multiple sources can be costly and time-consuming to build, and managing the data lifecycle is complex.

Many organizations are turning to security data lakes to manage security data from multiple data sources and to integrate with other security tools. These data lakes help centralize and store unlimited amounts of data to power investigations, analytics, threat detection, and compliance initiatives. It also makes it possible to combine the organization's own data with enriched data from other sources for deeper context.

With Amazon Security Lake, organizations will be able to store, analyze, and understand the data collected from both cloud and on-premises infrastructure, the company said. Because Amazon Security Lake supports the Open Cybersecurity Schema Framework (OCSF), an open specification for security telemetry data, it can ingest data from a number of third-party providers. Having the data available in OCSF format means security teams can use the analytics tool of their choice to uncover malicious activity.

“After customers choose their data sources, Amazon Security Lake automatically aggregates and normalizes data from AWS, combines it with third-party sources that support OCSF (an open standard), and optimizes it into a format that is easy to store and query,” AWS said in a statement.   

Amazon Security Lake aggregates data from AWS services, such as CloudTrail, Lambda, AWS Security Hub, GuardDuty, and AWS Firewall Manager, as well as from firewalls and endpoint security products from other companies. Several dozen companies have announced integrations with Amazon Security Lake, including Cisco, CrowdStrike, Palo Alto Networks, Barracuda, Lacework, Trend Micro, and Laminar. Security teams can analyze the data using Amazon's own security services such as Amazon Athena, Amazon OpenSearch, and Amazon SageMaker, as well as third-party providers such as IBM, Splunk, Sumo Logic, Securonix, and SentinelOne.

The data lakes are built using Amazon Simple Storage Service (S3) and AWS Lake Formation, the company said.

AWS Unveils Amazon Security Lake at re:Invent 2022

The threat actor behind an August intrusion used data from that incident to access customer data stored with a third-party cloud service provider, and affiliate GoTo reports breach of development environment.

An attacker who breached the software development environment at LastPass this August and stole source code and other proprietary data from the company appears to have struck the password management firm again.

On Wednesday, LastPass disclosed it is investigating a recent incident where someone using information obtained during the August intrusion managed to access source code and unspecified customer data stored within an unnamed third-party cloud storage service. LastPass did not disclose what kind of customer data the attacker might have accessed but maintained that its products and services remained fully functional.

**Unusual Activity**

"We recently detected unusual activity within a third-party cloud storage service, which is currently shared by both LastPass and its affiliate, GoTo," LastPass said. "We immediately launched an investigation, engaged Mandiant, a leading security firm, and alerted law enforcement."

LastPass' statement coincided with one from GoTo, also on Wednesday, that referred to what appeared to be the same unusual activity within the third-party cloud storage-service. In addition, GoTo's statement described the activity as impacting its development environment but offered no other details. Like LastPass, GoTo said its videoconferencing and collaboration services remained fully functional while it investigates the incident.

It is unclear if the apparent breach of GoTo's development environment is related in any way to the August intrusion at LastPass or if the two incidents are entirely separate. Both companies declined to answer a Dark Reading question on whether the two incidents might be related.

The new breach at LastPass suggests that attackers may have accessed more data from the company in August than previously thought. LastPass has previously noted the intruder in the August breach gained access to its development environment by stealing the credentials of a software developer and impersonating that individual. The company has maintained since then that the threat actor did not gain access to any customer data or encrypted password vaults because of the design of its system and the controls it has in place.

**Were LastPass' Security Controls Strong Enough?**

Those controls include a complete physical and network separation of the development environment from the production environment and ensuring the development environment contains no customer data or encrypted vaults. LastPass has also noted that it does not have any access to the master passwords to customer vaults, thereby ensuring that only the customer can access it.

Michael White, technical director and principal architect at Synopsys Software Integrity Group, says LastPass' practice of separating dev and test and making sure that no customer data is used in dev/test are certainly good practices and in line with recommendations.

However, the fact that a threat actor managed to gain access to its development environment means they potentially had the ability to do a lot of damage.

"The short answer is that we simply cannot know based on what has been said publicly," White says. "However, if the impacted dev systems have any access to common internal tools used for software build and release — for example, source code repositories, build systems, or binary artifact storage — it could allow an attack to insert a surreptitious back door into the code."

So, the mere fact that LastPass might have separated development and test from its production environment is not enough guarantee that customers were fully protected, he says.

LastPass itself has only confirmed the threat actor behind the August breach as accessing its source code and some other intellectual property. But it's unclear if the actor might have done other damage as well, researchers tell Dark Reading.

Joshua Crumbaugh, CEO at PhishFirewall, says development environments tend to present easy targets for threat actors to inject malicious code without being detected. "That malicious code is like finding a needle that you don't know to look for in a haystack of needles," he says.

Development environments are also known for having hardcoded credentials and for insecure storage of API keys, user credentials, and other sensitive information. "Our research continuously demonstrates that development teams are one of the least security aware departments at most organizations," Crumbaugh says. He adds that LastPass' breach sequel suggests they didn't completely trace the attackers' actions after the first breach.

LastPass Discloses Second Breach in Three Months

A vulnerability discovered in GitHub Actions could allow an attacker to poison a developer's pipeline, highlighting the risk that insecure software pipelines pose.

An attacker submitting changes to an open source repository on GitHub could cause downstream software projects that include the latest version of a component to compile updates with malicious code.

That's according to software supply chain security firm Legit Security, which said in an advisory published on Dec. 1 that this "artifact poisoning" weakness could affect software projects that use GitHub Actions — a service for automating development pipelines — by triggering the build process when a change is detected in a software dependency. 

The vulnerability is not theoretical: Legit Security simulated an attack on the project that manages Rust, causing the project to recompile using a customized — and malicious — version of the popular GCC software library, the company stated in the advisory.

The problem likely affects a large number of open source projects because maintainers typically will run tests on contributed code before they actually analyze the code themselves, says Liav Caspi, chief technology officer of Legit Security.

"It is a common pattern today," he says. "A lot of open source projects today, upon a change request, they run a bunch of tests to validate the request because the maintainer does not want to have to review the code first. Instead, it automatically run tests."

The attack takes advantage of the automated build process through GitHub Actions. In the case of the Rust programming language, the vulnerable pattern could have allowed an attacker to execute code in a privileged way as part of the development pipeline, stealing repository secrets and potentially tampering with code, Legit Security said.

"To put it simply: in a vulnerable workflow, any GitHub user can create a fork that builds an artifact," the company stated in its advisory. "Then inject this artifact into the original repository build process and modify its output. This is another form of a software supply chain attack, where the build output is modified by an attacker."

The vulnerability enables an attack similar to the malware-insertion attack that targeted CodeCov and, through that company's software, its downstream customers.

"\[T\]he lack of native GitHub implementation for cross-workflow artifacts communication led many projects and the GitHub Actions community to develop insecure solutions for cross-workflow communication and made this threat highly prevalent," Legit Security stated in the advisory.

GitHub confirmed the issue and paid a bounty for the information, while Rust fixed its vulnerable pipeline, Legit Security stated.

    

Source: Legit Security

**Software Supply Chain Needs Security**

The vulnerability is the latest security issue to affect software supply chains. Industry and government agencies have increasingly sought to bolster the security of open source software and software provided as a service.

In May 2021, for example, the Biden administration released its executive order on Improving the Nation's Cybersecurity, a federal rule that, among other requirements, mandates that the government will require baseline security standards for any software its purchases. On the private industry side, Google and Microsoft have pledged billions of dollars to shore up security in the open source ecosystem, which provides the code that comprises more than three-quarters of the average application's codebase.

**Logical, But Vulnerable**

The security issue belongs to a hard-to-find class of problems known as logic issues, which include issues with permissions, the potential for forked repositories to be inserted into a pipeline, and a lack of differentiation between forked and base repositories.

Because software projects often use automated scripts to check code submissions before forwarded them to the maintainers, pull requests will be run through automation before any human checks them for malicious code. While the automation saves time, it also should be considered a way for attackers to insert malicious code into the pipeline.

"When you are doing open source development, the problem is bigger, because you are accepting contribution from anyone in the world," Caspi says. "You are executing things that you cannot trust."

GitHub acknowledged the issue and expanded the ways of excluding submissions from outside collaborators from being automatically inserted into the Actions pipeline. The company updated its GetArtifact and ListArtifacts APIs with the goal of providing more information to help determine whether an artifact can be trusted.

"Anyone that does anything like the Rust project did — trusting the input from a third party — then they are still vulnerable," Caspi says. "It is a logic problem. GitHub just made it easier to write a safer script."

Artifact Poisoning in GitHub Actions Imports Malware via Software Pipelines

Though there have been fewer than expected publicly reported attacks involving the vulnerability, nearly three-quarters of organizations remain exposed to it.

The Log4j vulnerability continues to present a major threat to enterprise organizations one year after the Apache Software Foundation disclosed it last November — even though the number of publicly disclosed attacks targeting the flaw itself has been less than many might have initially expected.

A high percentage of systems still remain unpatched against the flaw, and organizations face challenges in finding and remediating the issue and then preventing the flaw from being reintroduced into the environment, security researchers say.

"The fact that Log4j is used in \[nearly\] 64% of Java applications and only 50% of those have updated to a fully fixed version means attackers will continue to target it," says David Lindner, CISO at Contrast Security. "At least for now, attackers continue to have a field day in finding paths to exploit through Log4j."

**Multiple Attacks But Fewer Than Expected**

The Log4j flaw (CVE-2021-44228), commonly referred to as Log4Shell, exists in Log4j's Java Naming and Directory Interface (JNDI) function for data storage and retrieval. It gives remote attackers a trivially easy way to take control of vulnerable systems — a problem given that Log4J is used in virtually every Java application environment. Security researchers consider it as one of the most significant vulnerabilities in recent years because of its prevalence and the relative ease with which attackers can exploit it.

Over the past year, there have been numerous reports about threat actors targeting the flaw as a way to gain initial access into a target network. Many of these attacks have involved nation-state-backed advanced persistent threat (APT) groups from China, North Korea, Iran, and other countries. In November, for instance, the US Cybersecurity and Infrastructure Security Agency (CISA) warned about an Iran-government-backed APT group exploiting the Log4j vulnerability in an unpatched VMware Horizon server to deploy cryptomining software and credential harvesters on a federal network.

The warning was similar to one from Fortinet in March about Chinese threat actor Deep Panda using the identical vector to deploy a backdoor on target systems and another from Ahn Labs about North Korea's Lazarus Group distributing its own backdoor the same way. Others such as Microsoft have also reported observing state actors such as Iran's Phosphorous group and China's Hafnium threat actor using Log4 to drop reverse shells on infected systems.

Despite such reports — and several others about financially motivated cybercrime groups targeting Log4j — the actual number of publicly reported compromises involving Log4 has remained comparatively low, especially when compared to incidents involving Exchange Server vulnerabilities like ProxyLogon and ProxyShell. Bob Huber, chief security officer at Tenable, says the scale and scope of reported attacks have been surprisingly lower than expected, considering the simplicity of the vulnerability and the attack path. "Only recently have we seen some significant evidence of targeting, as noted by recent nation state activity from CISA," Huber says.

**Undiminished Threat**

However, that does not mean the threat from Log4j has diminished over the past year, security researchers note.

For one thing, a large percentage of organizations remain as vulnerable to the threat as they were a year ago. An analysis of telemetry related to the bug that Tenable recently conducted showed 72% of organizations were vulnerable to Log4j, as of Oct. 1. Tenable found that 28% of organizations globally have fully remediated against the bug. But Tenable found that organizations which had remediated their systems often encountered Log4j again and again as they added new assets to their environments.

In many instances — 29%, in fact — servers, Web applications, containers, and other assets became vulnerable to Log4j soon after initial remediation.

"Assuming organizations build the fix into the left side of the equation — during the build pipeline for software — rates of reintroduction should diminish," Huber says. "Much of the rate of reintroduction and change depends greatly on an organization's software release cycle."

Also, despite almost ubiquitous awareness of the flaw within the cybersecurity community, vulnerable versions of Log4j remain vexingly hard to find at many organizations because of how applications use it. Some applications might use the open source logging component as a direct dependency in their applications, and in other instances an application might use Log4j as a transitive dependency — or a dependency of another dependency, says Brian Fox, CTO at Sonatype.

"Since transitive dependencies are introduced from your direct dependency choices, they may not always be known or directly visible to your developers," Fox says.

In many cases, when the Apache Foundation first disclosed Log4Shell, companies had to send out thousands of internal emails, collect results in spreadsheets, and recursively scan file systems, Fox says. "This cost companies valuable time and resources to patch the component and prolonged the magnitude of the vulnerability's malicious effect," he says.

Data from the Maven Central Java repository that Sonatype maintains shows that 35% of Log4 downloads currently continue to be of vulnerable versions of the software. "Many companies are still trying to build their software inventory before they can even begin a response and are unaware of the implications of transitive dependencies," Fox says.

Because of all of the issues, the US Department of Homeland Security review board earlier this year concluded that Log4 is an endemic security risk that organizations will need to contend with for years. Members of the board assessed that vulnerable instances of Log4j will remain in systems for many years to come and put organizations at risk of attack for the foreseeable future.

**The One Positive Outcome**

Security researchers tracking the bug say that the positive fallout from Log4j is the heightened attention it has drawn to practices such as software composition analysis and software bill of materials (SBOM). The challenges that organizations have faced just determining whether they are vulnerable or where the vulnerability might exist in their environment has fostered a better understanding of the need for visibility into all the components in their codebase — especially those from open source and third-party sources.

"The investigation into the Log4J issue has reaffirmed the need for better software supply chain attestation in addition to SBOMs that keep up with the speed of DevOps," says Matthew Rose, CISO at ReversingLabs. "Application security and architecture teams have realized that just looking for risk in parts of the application like source code, APIs, or open source packages is not enough. They now realize that a complete understanding of the application's architecture is just as important as finding SQLI or cross-site scripting bugs (XSS)," he says.

One Year After Log4Shell, Most Firms Are Still Exposed to Attack

The Hell's Keychain attack vector highlights common cloud misconfigurations and secrets exposure that can pose grave risk to enterprise customers.

A vulnerability in IBM Cloud databases for PostgreSQL could have allowed attackers to launch a supply chain attack on cloud customers by breaching internal IBM Cloud services and disrupting the hosted system's internal image-building process.

Security researchers from Wiz discovered the flaw, which they dubbed "Hell's Keychain." It included a chain of three exposed secrets paired with overly permissive network access to internal build servers, the researchers revealed in a blog post published Dec. 1. 

While now patched, the vulnerability is significant in that it represents a rare supply-chain attack vector impacting the infrastructure of a cloud service provider (CSP), Wiz CTO Ami Luttwak tells Dark Reading. The discovery also uncovers a class of PostgreSQL vulnerabilities affecting most cloud vendors, including Microsoft Azure and Google Cloud Platform.

"This is a first-of-a-kind supply-chain attack vector, showing how attackers might be able to leverage mistakes in the build process to take over the entire cloud environment," he says.

Specifically, researchers uncovered "major risk caused by improper sanitation of build secrets from container images, allowing for an attacker to gain write access to the central container image repository," Luttwak says. This would have allowed the actor to run malicious code in customers’ environments and modify the data stored in the database.

"Modifications to the PostgreSQL engine effectively introduced new vulnerabilities to the service," the researchers wrote in their post. "These vulnerabilities could have been exploited by a malicious actor as part of an extensive exploit chain culminating in a supply-chain attack on the platform."

As mentioned, the ability to use PostgreSQL to breach IBM Cloud is not unique to the service provider, researchers said. Wiz already has found similar vulnerabilities in other CSP environments, which they plan to disclose soon and which highlight a broader issue of cloud misconfigurations that pose a supply chain threat to enterprise customers.

The existence of the flaw also highlights how improper management of secrets — or long-lived authentication tokens for cloud APIs or other enterprise systems — can impose a high risk of unwanted intrusion by attackers on an organization using a cloud provider, Luttwak says.

"Finding and utilizing exposed secrets is the No. 1 method for lateral movement in cloud environments," he says.

For now, the researchers said they worked with IBM to remedy the issue in IBM Cloud and no customer mitigation action is required.

**Uncovering the Chain**

Researchers were doing a typical audit of IBM Cloud's PostgreSQL-as-a-service to find out if they could escalate privileges to become a "superuser," which would allow them to execute arbitrary code on the underlying virtual machine and continue challenging internal security boundaries from there.

Based on their experience, they said the ability to carry out a supply chain attack on a CSP lies in two key factors: the forbidden link and the keychain.

"The forbidden link represents network access — specifically, it is the link between a production environment and its build environment," the researchers wrote. "The keychain, on the other hand, symbolizes the collection of one or more scattered secrets the attacker finds throughout the target environment."

On its own, either scenario is "unhygienic," but not critically dangerous. However, "they form a fatal compound when combined," the researchers said.

Hell’s Keychain held three specific secrets: a Kubernetes service account token, a private container registry password, and continuous integration and delivery (CI/CD) server credentials.

Combining this chain with the so-called forbidden link between Wiz's personal PostgreSQL instance and IBM Cloud databases’ build environment allowed researchers to enter IBM Cloud’s internal build servers and manipulate their artifacts, the researchers said.

**Implications for Cloud Security**

The scenario presented in Hell's Keychain represents a broader problem within the cloud security community that demands attention and remediation, the researchers said. To wit: scattered plaintext credentials that are found across cloud environments that impose a huge risk on an organization, impairing service integrity and tenant isolation, they said.

For this reason, secret scanning at all stages of the pipeline is crucial, including in CI/CD, code repo, container registries, and within the cloud, Luttwak says.

"Furthermore, lockdown of privileged credentials to the container registry is crucial, as these credentials are often overlooked but are actually the keys to the kingdom," he adds.

CSP customers also should consider image signing verification via admission controllers to ensure these sort of attacks are prevented entirely, Luttwak says.

Hell's Keychain also highlights a common misconfiguration in the use of the popular Kubernetes API for container management within the cloud — pod access, ''which can lead to unrestricted container registry exposure," he says.

Another best practice the researchers recommend is any organization — CSP or otherwise — deploying a cloud environment can take is to impose strict network controls between the Internet-facing environment and the organization's internal network in the production environment, so attackers can't gain a deeper foothold and maintain persistence if they do manage to breach it.

Source

DARKReading