Thousands of corporate mobile apps developed by businesses for use by their customers contain hardcoded AWS tokens that can be easily extracted and used to access the full run of corporate data stored in cloud buckets.

Thousands of customer-facing Android and iOS mobile apps — including banking apps — have been found to contain hardcoded Amazon Web Services (AWS) credentials that would allow cyberattackers to steal sensitive information from corporate clouds.

Symantec researchers uncovered 1,859 business apps that use hardcoded AWS credentials, specifically access tokens. Of these, three-quarters (77%) contain valid AWS access tokens for logging into private AWS cloud services; and close to half (47%) contain valid AWS access tokens that also crack open millions of private files housed in Amazon Simple Storage Service (Amazon S3) buckets.

That means that a malicious-minded user of the app could easily extract the tokens and be off to the data-theft races, tapping into the cloud resources of the businesses that created the applications.

**Thanks, Mobile Software Supply Chain**

This unfortunate state of affairs is thanks to a mobile code supply chain issue, Symantec researchers said — vulnerable components that allow developers to embed hardcoded access tokens.

"We discovered that over half (53%) of the apps were using the same AWS access tokens found in other apps," they said in an analysis on Sept. 1. "Interestingly, these apps were often from different app developers and companies. \[Eventually\] the AWS access tokens could be traced to a shared library, third-party SDK, or other shared component used in developing the apps."

The firm found that these shared, hardcoded AWS tokens are used by in-house app developers for a variety of reasons, including downloading or uploading large media files, recordings, or images from the company cloud; accessing configuration files for the app; collecting and storing user-device information; or accessing individual cloud services that require authentication, such as translation services. However, the tokens' reach into the cloud is often far greater than the developer may realize.

"The problem is, often the same AWS access token exposes all files and buckets in the Amazon S3 cloud, often corporate files, infrastructure files and components, database backups, etc.," according to the analysis. "Not to mention cloud services beyond Amazon S3 that are accessible using the same AWS access token."

As an example, one of the apps uncovered by the analysis was created by a B2B company that offers an intranet and communication platform. It also provides a mobile software-development kit (SDK) for customers to use to access the platform.

"Unfortunately, the SDK also contained the B2B company's cloud infrastructure keys, exposing all of its customers' private data on the B2B company's platform," Symantec researchers noted, adding that they notified all organizations using vulnerable apps of the issue. "Their customers' corporate data, financial records, and employees' private data was exposed. All the files the company used on its intranet for over 15,000 medium-to-large-sized companies were also exposed."

The same situation held true for a collection of mobile banking apps on iOS that rely on the AI Digital Identity SDK for authentication. The SDK embeds AWS tokens that could be used to access private authentication data and keys belonging to every banking and financial app using it, as well as 300,000 banking users' biometric digital fingerprints used for authentication, and other personal data (names, dates of birth, and more).

"Apps with hardcoded AWS access tokens are vulnerable, active, and present a serious risk," Symantec researchers concluded. "\[And\] this is not an uncommon occurrence."

****Avoiding Cloud Compromise via Mobile Apps****

Organizations can take steps to ensure that the apps they build for their customers don't unwittingly offer a path to cyberespionage, according to Scott Gerlach, co-founder and CSO at StackHawk.

"Adding DevSecOps tools, like secret scanning, to continuous integration/continuous development pipelines (CI/CD) can help ferret out these types of secrets when building software," he noted in a statement. "And it's critical that you understand how to manage and securely provision AWS and other API keys/tokens to prevent unwarranted access."

From a design perspective, developers can also replace hardcoded credentials with API calls to a repository or software as-a-service (SaaS) vault, or to use temporary tokens, according to Tony Goulding, cybersecurity evangelist at Delinea.

"\[That way\] they can pull a credential or key down in real-time that doesn't persist on the device, in the app, or a local config file," he said in a statement. "An alternative approach is to use the AWS STS service to provision temporary tokens to grant access to AWS resources. They're similar to their long-term brethren except they have a short lifespan that's configurable — as little as 15 minutes. Once they expire, AWS won't recognize them as valid, preventing an illicit API request using that token."

AWS Tokens Lurking in Android, iOS Apps Crack Open Corporate Cloud Data

Threat hunters can help build defenses as they work with offensive security teams to identify potential threats and build stronger threat barriers.

Over the last few years, an influx of high-profile industry security issues (PDF) have placed offensive tactics among the top priorities for corporations to help mitigate the risk of a potential attack. With many companies opting to continue remote and hybrid working environments, potential security risks cannot go ignored or be left to chance, and an emphasis on developing greater defensive security tactics, working in tandem with offensive security teams, is essential for identifying behaviors of potential threats and building stronger barriers against evolving challengers.

Threat hunting, in particular, has emerged as a must-have security component for companies. It encompasses the tasks of identifying patterns of threat behaviors and hunting for anomalies and changes occurring in an environment based on suspicious activity — with the goal of building defenses to combat threats.

But what makes a successful threat-hunting program? The reality is that identifying suspicious activity may not be as straightforward as it seems. It requires a comprehensive approach with proactive manual detection, constant communication between teams, and an investment in the right people to bring the process to life.

**Hunting for the Right Skills**

Threat hunting requires a human touch to thoroughly review suspicious patterns and scour the environment for threats that haven't yet been identified by a company's existing security tooling and processes. It's a heavily strategic game of cat and mouse to find potential adversaries and advanced persistent threats (APTs), predict their next move, and stop them in their tracks.

A successful threat hunter needs to have a thorough understanding of their environment, the known threats their team has faced, and the ability to problem-solve and think critically about hidden avenues adversaries could take to gain access. In a way, this is the ultimate detective work, and it becomes the building blocks for designing better defensive protocols. Investing in the right people on the team and fostering a culture of open communication is essential.

To receive leads or hunt ideas, Adobe's threat-hunting team has created a messaging bot app that security teams, such as the security operations center or incident response, can use to have seamless collaboration with the hunt team. Once hunts are completed, hunt reports are shared with the cross-functional security teams and relevant stakeholders to improve the existing security posture of the organization.

The hunt team works hand-in-hand with the detection function to help improve current methods and input new data based on emerging tactics used by adversaries. They also collaborate closely with the team responsible for central operational security data to help identify gaps, misconfigurations, and bolster enrichments to help security teams utilize that data more effectively.

However, while threat hunting tends to mainly rely on manual processes, automated processes and machine learning can certainly aid in the hunting effort. Aggregated data analytics can help to quickly find anomalies in data patterns within a company's network, shortening the time teams need to spend combing through data.

At Adobe, we are building multiple UEBA (user and entity behavior analytics) pipelines using machine learning and advanced data analytics to review large volumes of log data and help us spot anomalies that indicate a user's or entity's behavior change. These anomalies are turned into hunt leads (or alerts) after further enrichment and correlation for human review and escalation when needed.

**Stopping Adversaries in their Tracks**

With the right team in place, security teams can begin mapping out their plan of attack and strategy to identify APTs:

*   Rally behind a hypothesis of how adversaries could potentially gain access to the network
*   Create a clear goal for the program (e.g., reducing time adversaries spend in the network, reduce the number of high-impact threats, etc.)
*   Analyze data for anomalies and work cross-team to build new, improved defenses

Not all threat-hunting campaigns will be equally successful, so it's just as important to create a plan for tailoring threat-hunting programs as your company collects more insights on current data trends and adversaries. Be honest with your teams about what's working, what isn't, and new ways to leverage machine learning and other tools to support your goals.

When combined with offensive tactics, threat hunting is a valuable addition to your security efforts. It should be viewed as an ever-evolving strategic approach to identify potential issues, and an essential component of a successful, comprehensive security program.

The Makings of a Successful Threat-Hunting Program

TAP assures its customers that it stopped data theft in a recent cyberattack, but the Ragnar Locker ransomware group says it made off with user info.

Despite TAP Air Portugal's claims that a recent cyberattack was stopped and no airline customer data was compromised, the Ragnar Locker ransomware gang posted on its leak site that it's got the goods.

On Aug. 26, TAP announced it was targeted in an unsuccessful cyberattack.

"No facts have been found to conclude that there has been improper access to customer data," TAP tweeted. "The website and app still have some instability."

Yet, according to reports, Ragnar Locker responded on Aug. 31 claiming that it had indeed breached TAP's systems and stolen customer data, and included a screenshot of what it said was a sample of the exfiltrated records, loaded with personal identifiable information (PII).

TAP Air Portugal is sticking to the company's original position, releasing a new statement on Sept. 1 reiterating the company blocked the cyberattack, adding, however, that the airline's app, website, and miles program are still "registering some instability."

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

Ragnar Locker Brags About TAP Air Portugal Breach

IT has to get its hands around cloud data sprawl. Another area of focus should be on ghost data, as it expands the organization's cloud attack surface.

Cloud sprawl is a big issue for organizations, with business teams to spinning up cloud systems and services on their own, often without IT oversight. That leads to cloud data sprawl as data is scattered across different environments. If IT doesn’t know about the cloud systems and services, then IT is also not managing the data being collected, processed, and stored there.

We all know about shadow IT, the systems and network devices in the organization’s environment that IT is not managing. Similarly, shadow data refers to unmanaged data store copies and snapshots or log data not part of IT’s backup and recovery strategy. Researchers at Cyera estimate that 60% of the data security posture issues present in cloud accounts stem from unsecured sensitive data.

Then there is the problem of ghost data.

When data gets deleted from cloud systems, it isn’t fully gone. Copies linger in backups or snapshots of data stores. Ghost data refers to those copies left behind after the original has been deleted, and Cyera’s recent analysis show that enterprises have quite a lot of it.

After scanning the three major cloud providers (Amazon Web Services, Azure, and Google Cloud), Cyera researchers found that over 30% of scanned customer cloud data stores are ghost data and more than 58% contain sensitive, or very sensitive, data. For example, researchers found unsecured database snapshots in non-production environments that contained sensitive customer data where the original database had been destroyed. Researchers also uncovered sensitive personal and authentication data in plain text where the production data and application were no longer in use.

Ghost data usually has no business value – the data was deleted for a reason -- and having it around unnecessarily increases business risk. Attackers don’t care if they get their hands on the original sensitive information or the copy because to them, all data has value, regardless of the form it takes. Organizations still are on the hook if the attackers get their hands on ghost data. The data security provisions of industry-specific regulations like HIPAA, PCI DSS, and the Sarbanes-Oxley Act still apply.

Organizations need to reduce cloud data exposure to reduce data sprawl. Proper data hygiene across clouds will also help clean up data when it is no longer in use.

On a final note, ghost data can increase the organization’s cloud costs: Researchers found over $50,000 in excess data store snapshots being retained in a cloud environment.

Ghost Data Increases Enterprise Business Risk

Neopets has confirmed that its IT systems were compromised from January 2021 through July 2022, exposing 69 million user accounts and source code.

Neopets has released an "Important Announcement" urging its members to update their passwords and confirming that the company's IT systems were compromised.

Neopets is a game that lets players create, and care for, virtual pets inside a fantasy world.

"It appears that email addresses and passwords used to access Neopets accounts may have been affected," the company explained. "We strongly recommend that you change your Neopets password."

The admission comes just weeks after a cyberattacker was reportedly shopping a stolen Neopets database with 69 million member records and the Neopets source code for four bitcoin (which is currently worth less than $80,000, and falling).

The company confirmed that it learned about the attack on the same day the data was put up for sale, July 20.

Compromised Neopets member information includes names, email addresses, usernames, dates of birth, gender, IP addresses, Neopets PINs, and hashed passwords, as well as data generated during game play.

"As part of our ongoing commitment to the safety and privacy of the Neopets' player information in our care, we have reset players' passwords and are working on adding multifactor authentication to better safeguard your account access," Jim Czulewicz, president and CEO of Neopets owner JumpStart Games, said in a statement.

He added, "We have also enhanced the protection of our systems, including by further strengthening our network monitoring, authentication, and system protection."

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

Neopets Hackers Had Network Access for 18 Months

"JuiceLedger" has escalated a campaign to distribute its information stealer by now going after developers who published code on the widely used Python code repository.

Security researchers have identified a previously unknown group dubbed "JuiceLedger" as the threat actor behind a recent and first-known phishing campaign specifically targeting users of the Python Package Index (PyPI).

The threat actor first surfaced early this year and is focused on distributing a .NET-based malware called JuiceStealer for searching and stealing browser and cryptocurrency-related information from infected systems.

Initially, JuiceLedger distributed the information stealer via fraudulent Python installer applications. But starting in August, researchers from SentinelOne and Checkmarx observed the attacker also engaged in attempts to poison Python packages on the PyPI repository — presumably to distribute its malware to a wider audience.

The threat actor's modus operandi has involved targeting PyPI users with a phishing email informing them about Google implementing a new validation process for packages published on PyPI. The email claimed the measure was in response to a big increase in malicious PyPI packages getting uploaded to the registry. It warned developers to expeditiously validate their code packages with Google to avoid having them removed from the registry. "Packages not validated before September will be removed promptly," the phishing email noted.

PyPI users who clicked on the link were directed to a webpage, spoofed to look exactly like PyPI's login page. When users entered their credentials there, the page was designed to send that information to a JuiceLedger-controlled domain (linkedopports\[dot\]com). The caper appears to have convinced at least two developers to part with their credentials, which gave JuiceLedger a way to access and poison their relatively widely used PyPI packages with malicious code.

One of the infected packages (version 0.1.6 of "exotel"), for instance, had more than 480,000 total downloads at the time it was infected. The other package (versions 2.0.2 and 4.0.2 of "spam") had some 200,000 downloads. PyPI administrators have since removed both packages, according to Checkmarx.

When installed in a development environment, the code can search for Google Chrome passwords, query Chrome SQLite files, and launch a Python installer contained in the zip named “config.exe," SentinelOne said. The infostealer also looks for logs that contain the word "vault," likely because it is searching for cryptocurrency vaults, and reports the information back to an attacker-controlled command-and-control server over HTTP.

**Broad Campaign**

PyPI admins have also removed "several hundred" typosquatted packages that JuiceLedger published to PyPI as part of a broader effort to distribute its infostealer via the popular Python code repository, both SentinelOne and Checkmarx noted. Their analysis showed the threat actors had inserted a short code snippet in the packages for retrieving a signed variant of JuiceStealer from an attacker-controller URL and executing it.

The code in the typosquatted packages was similar to the code that JuiceLedger had inserted into the two legitimate code packages via its phishing campaign. The attacker-controlled URL that the typosquatted packages communicated with was also the same as the same the one that the poisoned versions of "exotel" and "spam" packages communicated. This allowed researchers at SentinelOne and Checkmarx to conclude JuiceLedger was responsible for both, the PyPI phishing campaign and for uploading the typosquatted packages to PyPI.

JuiceLedger's attack on PyPI in August represents a dangerous escalation in the threat actor's efforts to distribute its information stealer, SentinelOne said. "In August 2022, the threat actor engaged in poisoning open-source packages as a way to target a wider audience with the infostealer through a supply chain attack, raising the threat level posed by this group considerably."

**Popular — but Not the Only — Target**

PyPI recently has become a popular target for attackers trying to poison software supply chains. Countless organizations use the code published in the repository to build their applications. So, by poisoning packages on the registry, attackers can potentially reach a wide audience with relatively little effort. Recent examples include threat actors inserting malicious package installation code in 10 packages published to PyPI, another incident where some 300 developers inadvertently downloaded a package for installing Cobalt Strike from the registry and one where a school-age hacker uploaded ransomware to the registry to see what would transpire.

PyPI is by far not the only code repository that attackers have targeted recently. Security vendors have reported numerous similar incidents involving other widely used registries such as npm and Maven Central. The trend has heightened attention on software supply chain security issues, especially because of the potential for nation-state backed adversaries — like the Russian threat actor behind the SolarWinds compromise — exploiting the same tactic in their attack campaigns.

Attackers are taking advantage of the fact that developers and organizations will always need to use open source packages, says Amitai Ben, threat intelligence researcher at SentinelOne.

The best way to minimize exposure for those contributing open source code to public repositories is to enable two-factor authentication (2FA) on their user account in package managers. That minimizes the risk of account takeover by malicious actors.

Users of open source packages, meanwhile, need to know that popular packages are often connected to Git repositories from which the development process is taking place. "Discrepancies between the repository and the package on the package manager can be a sign of suspicious activity and account takeover," Ben says.

Threat Actor Phishing PyPI Users Identified

The expanding Internet of Things ecosystem is seeing a startling rate of vulnerability disclosures, leaving companies with a greater need for visibility into and patching of IoT devices.

Rising numbers of documented security issues in Internet of Things (IoT) devices mean that businesses have a new patch management issue brewing, cybersecurity, experts say.

A combination of more connected products, greater scrutiny by researchers, and regulations requiring disclosure of vulnerabilities has resulted in a rising tide of disclosed bugs. Those found in products considered to be part of the Extended Internet of Things (XIoT), for example, jumped 57% in the first half of the year, compared with the prior six months, Claroty stated in a recent report.

Embedded IoT devices have meanwhile jumped to account for 15% of the XIoT vulnerabilities, up from 9% in the second half of 2021.

This rapidly expanding landscape of IoT devices and infrastructure means that companies need to ensure visibility, not only into their IoT devices, but all the systems that manage those devices, and be ready to quickly patch those devices, says Sharon Brizinov, director of research for Claroty.

"The networks \[have become\] much more diverse than ever before, and that goes hand-and-hand with the fact that more security researchers are looking for vulnerabilities than ever before," he says. "So, more devices and more awareness and more security researchers investigating those devices means more vulnerabilities being disclosed."

    

XIoT vulnerability classified by embedded IoT, medical IoT, IT, and OT categories. Source: Claroty

This trend is only set to continue, according to experts. Companies will need to keep track of their IoT assets and, because vulnerability remediation typically requires a software update, evaluate whether deployed devices can easily be updated.  

Fewer vendors are trying to hide their security issues and are moving away from silent patching — a good development for security but one that contributes to the "noticeable increase" in the number of IoT vulnerabilities being publicly disclosed, says Deral Heiland, principal security researcher for IoT at Rapid7.

"If no data is made available to the public, then end users can't be aware of a potentially serious risk caused by a vulnerability and may delay patching," he notes. "So, vendors publishing in this way is a positive move."

**Growing Number of XIoT issues**

Overall, 747 vulnerabilities were disclosed in XIoT devices between the start of January and the end of June, a 57% jump from the prior six months, according to Claroty's "State of XIoT Security: 1H 2022" report. The affected products came from 86 different vendors, and for the first time, proactive disclosure by vendors became the second most common way that information on vulnerabilities was published, after disclosure by third-party firms. Independent researchers and the Zero Day Initiative were the third and fourth most common sources of vulnerability information.

Vendors as a group are not necessarily better at security — the numbers are driven by a few major firms, such as Siemens, that have implemented strong security programs, says Claroty's Brizinov. Siemens represented the top disclosure of XIoT vulnerabilities, at 214, with the second being Reolink at 87, followed by Schneider at 52, according to Claroty's report.

"There were some business decisions that led to this result — some decisions makers that decide to come clean," he says. "They understand that it is an important piece of information."  

Different initiatives have also fueled the rising rate of disclosures. The Internet of Things Cybersecurity Improvement Act of 2020 has put pressure on companies that provide IoT products to the government, while a consumer-focused program for creating security "nutrition labels" for IoT devices will likely drive consumers toward more security-conscious products.

**A Moving Definition of the Internet of Things**

Vulnerability-intelligence firm Risk Based Security, now part of Flashpoint, has also noted an increase in the number of security issues in products that could be considered part of the IoT ecosystem. The company, however, has stressed that the lack of a good definition for IoT devices makes it difficult to track the category.

Industrial monitoring devices, medical imaging equipment, IP video cameras, and electronic door locks are all connected to the Internet and allow digital communications to have impacts on the physical world. In its 2020 publication, "Foundational Cybersecurity Activities for IoT Device Manufacturers," the US National Institute of Standards and Technology (NIST) defined IoT devices as those that "have at least one transducer (sensor or actuator) for interfacing directly with the physical world and at least one network interface ... for interfacing with the digital world."

Claroty calls the category the Extended Internet of Things, and puts devices from medical, industrial, and commercial applications under one umbrella. The company has acknowledged that the products included in the XIoT category may not have been there last year because new devices have been released, connectivity added to previous products, and as new products push the definition of IoT.

For instance, as manufacturing, critical infrastructure, and city management have adopted connected devices, Siemens and other operations technology (OT) companies have transformed their products from industrial control systems to industrial IoT, cybersecurity has become a critical part of that transformation, Claroty's Brizinov says.

"In the past, there was a distinct separation between IT and OT — we could circle those domains and they would be separate," he says. "And then came IoT, and those circles intersected so there were some devices in both IT and OT."

Another growing aspect of IoT is mobile devices, such as smartphones and tablets. Many companies use mobile devices as a way to monitor and control their network of IoT devices, which means that the device is not the only component of the IoT ecosystem, but mobile devices and back-end servers must also be included.

For that reason, Rapid7 considers cloud components and management software to be part of the ecosystem.

"Typically, a mobile device as a standalone device would not be considered IoT," says Rapid7's Heiland. "When running software designed to interact, control, and/or manage an IoT solution, it does become part of the IoT products ecosystem and should be considered when evaluating the security of the IoT product."

Skyrocketing IoT Bug Disclosures Put Pressure on Security Teams

The proposed AMTSO guidelines offer a roadmap for comprehensive testing of IoT security products.

The Anti-Malware Testing Standards Organization (AMTSO) unveiled a list of proposed publishing standards for testing the efficacy of IoT security solutions.

AMTSO’s guidelines are intended to help organizations evaluate which tools are most effective and best suited to their environment. The document outlines six key areas:

*   **General principles:** All tests and benchmarks should focus on validating the end result and performance of protection delivered, instead of how the product functions on the backend.
*   **Sample selection:** For a relevant test of IoT security solution benchmarking, testers need to select samples that are still active, and that actually target the operating systems smart devices are running on.
*   **Determination of "detection":** Because of the differences between IoT security and traditional cybersecurity solutions, the guidelines suggest to use threats with admin consoles that can be controlled by the tester or to use devices where the attack will be visible if it happens.
*   **Test environment:** If the tester decides against using real devices in the testing environment, they should validate their approach by running their desired scenario with the security functionality of the security device disabled and checking the attack execution and success.
*   **Testing of specific security functionality:** The guidelines provide advice on different attack stages, including reconnaissance, initial access, and execution, and suggest testing each stage individually rather than going through the whole attack at once.
*   **Performance benchmarking:** The guidelines suggest differentiating between various use cases such as consumers vs. businesses, or the criticality of latency or reduced throughput per protocol, which depends on its purpose.

There's a lot of diversity in IoT devices, making it difficult to create a one-size-fits-all approach to security, says Tony Goulding, cybersecurity evangelist at Delinea. Some devices lack computational capacity, and not being able to deploy security agents or clients on the devices makes it difficult to enforce a centralized and consistent set of security policies.

"Threat actors recognize this and exploit the fact that these devices are particularly vulnerable to malware," he says. "As a security community, we strive to eliminate or choke vectors of attack that can give adversaries illicit access to our infrastructure, resulting in a data breach, ransomware attack, or taking critical OT infrastructure offline."

Industry regulations like PCI, HIPAA, and SOX focus on security and privacy guidelines in order to protect access to sensitive data and systems in traditional IT environments, Goulding says. Organizations should prioritize IoT products from vendors who have undergone such testing to help ensure such risks are mitigated in their product.

"Similarly, it's important to protect access to IoT devices that are used in sensitive environments," he says. "With no equivalent set of regulations, the AMTSO guidelines represent a step in the right direction to help IoT vendors test their products' ability to detect and prevent attacks."

**Secure IoT Critical for Organizations**

Many cybercriminals target IoT devices as their point of entry because they enable lateral movement within corporate networks, says Bud Broomhead, CEO at Viakoo. While security for vulnerable IoT devices is critically important for enterprises, the fact remains that IoT devices often lack automated methods for patching vulnerabilities, updating the firmware and digital certificates, or changing built-in passwords.

"Breached IoT devices are having devastating impacts, such as ransomware, data loss, changing the chemical balance in a municipal water supply, replacing real camera footage with deepfakes, or disrupting transportation systems," he says.

Because devices are so distributed and often of different makes and models, manually managing device security across multiple locations for cameras, kiosks, intercoms, and other equipment can be very difficult to accomplish at scale.

Goulding says while the proposed guidelines are a step in the right direction, more and stronger standards, widely enforced, are required. There's some progress, with Europe's ETSI EN 303 645 and California's "Security of Connected Devices" law. NIST in the US has pilot programs for cybersecurity labeling of consumer IoT devices.

"Until then, vendors and industry sectors will have different priorities," Goulding says.

New Guidelines Spell Out How to Test IoT Security Products

The insecurities exist in CI/CD pipelines and can be used by attackers to subvert modern development and roll out malicious code at deployment.

A pair of security vulnerabilities discovered in the GitHub environments of two very popular open source projects from Apache and Google could be used to stealthily modify project source code, steal secrets, and move laterally inside an organization.

The issues are continuous integration/continuous delivery (CI/CD) flaws that could threaten many more open source projects around the world, according to researchers at Legit Security, who found them affecting a Google Firebase project and a popular integration framework project run by Apache.

Researchers dubbed the vulnerability pattern "GitHub Environment Injection." It allows attackers to take control of a vulnerable project's GitHub Actions pipeline by creating a specially crafted payload written to a GitHub environment variable called "GITHUB\_ENV." 

Specifically, the issue exists in the way GitHub shares environment variables in the build machine, which can be manipulated to extract information, including the repository ownership credentials.

"The concept is that the build action itself trusts the code that is submitted for review in a way that you don't need anybody to review it," explains Liav Caspi, CTO and co-founder of Legit Security. "The mere fact that somebody makes a contribution tricks the build system into executing something about the code. There is a kind of automated test that runs, and you can make the test execute whatever you put there."

He adds: "The problem there is that anybody that makes a contribution could trigger that without the need for somebody to review it. So, that's very powerful."

**Don't Ignore Security for CI/CD Pipelines**

According to Caspi, his team found the flaws as a part of an ongoing investigation into CI/CD pipelines. With a surge in SolarWinds-style supply chain flaws, they'd particularly been seeking out weaknesses in the GitHub ecosystem, since it's one of the most popular source code management (SCM) systems in the open source world and in enterprise development — and thus a natural vehicle for injecting vulnerabilities into software supply chains.   

He explains that these flaws manifest both a design weakness in the way that the GitHub platform is designed and how different open source projects and enterprises use the platform.

"You could potentially write a very safe build script if you are super aware of the risks and circumvent a lot of risky operations," he explains. "But I think nobody is really aware of that, and there are a couple of mechanisms within GitHub Actions that are very dangerous that are used in everyday build operations."

He says that enterprise development teams should always assume zero trust with GitHub Action and other build systems.

"They should assume that the components they're using to build — whether it is a build plug-in or anything submitted to them — that an attacker could leverage that," he says. "And then they should isolate the environment and also review code in a way that it doesn't execute code submitted for you."

As Caspi explains, these flaws illustrate not only that the open source project itself a potential vector for supply chain vulnerabilities, but so is the code that makes up the CI/CD pipeline and its integration.

Both bugs have been patched.

Code-Injection Bugs Bite Google, Apache Open Source GitHub Projects

Apple continues a staged update process to address a WebKit vulnerability that allows attackers to craft malicious Web content to load malware on affected devices.

Apple has quietly rolled out more updates to iOS to fix an actively exploited zero-day security vulnerability that it patched earlier this month in newer devices. The vulnerability, found in WebKit, can allow attackers to create malicious Web content that allows remote code execution (RCE) on a user's device.

An update released Wednesday, iOS 12.5.6, applies to the following models: iPhone 5S, iPhone 6, iPhone 6 Plus, iPad Air, iPad mini 2, iPad mini 3, and iPod touch 6th generation.

The flaw in question (CVE-2022-32893) is described by Apple as an out-of-bounds write issue in WebKit. It was addressed in the patch with improved bounds checking. Apple acknowledged that the bug is under active exploit, and is urging users of affected devices to update immediately.

Apple had already patched the vulnerability for some devices — alongside a kernel flaw tracked as CVE-2022-32894 — earlier in August in iOS 15.6.1. That's an update that covered iPhone 6S and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation).

The latest round of patches appears to be Apple covering all its bases by adding protection for iPhones running older versions of iOS, noted security evangelist Paul Ducklin.

"We're guessing that Apple must have come across at least some high-profile (or high-risk, or both) users of older phones who were compromised in this way, and decided to push out protection for everyone as a special precaution," he wrote in a post on the Sophos Naked Security blog.

The dual coverage by Apple to fix the bug in both versions of iOS is due to the change in which versions of the platform run on which iPhones, Ducklin explained.

Before Apple released iOS 13.1 and iPadOS 13.1, iPhones and iPads used the same operating system, referred to as iOS for both devices, he said. Now, iOS 12.x covers iPhone 6 and earlier devices, while iOS 13.1 and later versions run on iPhone 6s and devices released after.

The other zero-day flaw that Apple patched earlier this month, CVE-2022-32894, was a kernel vulnerability that can allow for entire device takeover. But while iOS 13 was affected by that flaw — and thus got a patch for it in the earlier update — it does not affect iOS 12, Ducklin observed, "which almost certainly avoids the risk of total compromise of the operating system itself" on older devices, he said.

**WebKit: A Wide Cyberattack Surface**

WebKit is the browser engine that powers Safari and all other third-party browsers that work on iOS. By exploiting CVE-2022-32893, a threat actor can build malicious content into a website. Then, if someone visits the site from an affected iPhone, the actor can remotely execute malware on his or her device.

WebKit in general has been a persistent thorn in Apple's side when it comes to exposing users to vulnerabilities because it spreads beyond iPhones and other Apple devices to other browsers that use it — including Firefox, Edge, and Chrome — putting potentially millions of users at risk from a given bug.

"Remember that WebKit bugs exist, loosely speaking, at the software layer below Safari, so that Apple's own Safari browser isn't the only app at risk from this vulnerability," Ducklin observed.

Moreover, any app that displays Web content on iOS for purposes other than general browsing — such as in its help pages, its _"About"_ screen, or even in a built-in "minibrowser" — uses WebKit under the hood, he added.

"In other words, just 'avoiding Safari' and sticking to a third-party browser is not a suitable workaround \[for WebKit bugs\]," Ducklin wrote.

**Apple Under Attack**

While users and professionals alike have traditionally considered Apple's Mac and iOS platforms as more secure than Microsoft Windows — and this has generally been true for a number of reasons — the tide is beginning to turn, experts say.

Indeed, an emerging threat landscape showing more interest in targeting more ubiquitous Web technologies and not the OS itself has widened the target on Apple's back, according to a threat report released in January, and the company's defensive patching strategy reflects this.

Apple has patched at least four zero-day flaws this year, with two patches for previous iOS and macOS vulnerabilities coming in January and one in February — the latter of which fixed another actively exploited issue in WebKit.

Moreover, last year 12 of 57 zero-day threats that researchers from Google's Project Zero tracked were Apple-related (i.e., more than 20%), with issues affecting macOS, iOS, iPadOS, and WebKit.

Source

DARKReading