How an innocuous app morphed into a trojan – Week in security with Tony Anscombe

ESET research uncovers an Android app that initially had no harmful features but months later turned into a spying tool

The post How an innocuous app morphed into a trojan – Week in security with Tony Anscombe appeared first on WeLiveSecurity

/by

Shedding light on AceCryptor and its operation

ESET researchers reveal details about a prevalent cryptor, operating as a cryptor-as-a-service used by tens of malware families

The post Shedding light on AceCryptor and its operation appeared first on WeLiveSecurity

/by

Announcing the launch of GUAC v0.1

Brandon Lum and Mihai Maruseac, Google Open Source Security Team

Today, we are announcing the launch of the v0.1 version of Graph for Understanding Artifact Composition (GUAC). Introduced at Kubecon 2022 in October, GUAC targets a critical need in the software industry to understand the software supply chain. In collaboration with Kusari, Purdue University, Citi, and community members, we have incorporated feedback from our early testers to improve GUAC and make it more useful for security professionals. This improved version is now available as an API for you to start developing on top of, and integrating into, your systems.

The need for GUAC

High-profile incidents such as Solarwinds, and the recent 3CX supply chain double-exposure, are evidence that supply chain attacks are getting more sophisticated. As highlighted by the U.S. Executive Order on Cybersecurity, there’s a critical need for security professionals, CISOs, and security engineers to be able to more deeply link information from different supply chain ecosystems to keep up with attackers and prevent exposure. Without linking different sources of information, it’s impossible to have a clear understanding of the potential risks posed by the software components in an organization. 



GUAC aggregates software security metadata and maps it to a standard vocabulary of concepts relevant to the software supply chain. This data can be accessed via a GraphQL interface, allowing development of a rich ecosystem of integrations, command-line tools, visualizations, and policy engines. 



We hope that GUAC will help the wider software development community better evaluate the supply chain security posture of their organizations and projects. Feedback from early adopters has been overwhelmingly positive: 



“At Yahoo, we have found immense value and significant efficiency by utilizing the open source project GUAC. GUAC has allowed us to streamline our processes and increase efficiency in a way that was not possible before,” said Hemil Kadakia, Sr. Mgr. Software Dev Engineering, Paranoids, Yahoo.

The power of GUAC

Dynamic aggregation

GUAC is not just a static database—it is the first application that is continuously evolving the database pertaining to the software that an organization develops or uses. Supply chains change daily, and by aggregating your Software Bill of Materials (SBOMs) and Supply-chain Levels for Software Artifacts (SLSA) attestations with threat intelligence sources (e.g., OSV vulnerability feeds) and OSS insights (e.g., deps.dev), GUAC is constantly incorporating the latest threat information and deeper analytics to help paint a more complete picture of your risk profile. And by merging external data with internal private metadata, GUAC brings the same level of reasoning to a company’s first-party software portfolio.



Seamless integration of incomplete metadata

Because of the complexity of the modern software stack—often spanning languages and toolchains—we discovered during GUAC development that it is difficult to produce high-quality SBOMs that are accurate, complete, and meet specifications and intents. 



Following the U.S. Executive Order on Cybersecurity, there are now a large number of SBOM documents being generated during release and build workflows to explain to consumers what’s in their software. Given the difficulty in producing accurate SBOMs, consumers often face a situation where they have incomplete, inaccurate, or conflicting SBOMs. In these situations, GUAC can fill in the gaps in the various supply chain metadata: GUAC can link the documents and then use heuristics to improve the quality of data and guess at the correct intent. Additionally, the GUAC community is now working closely with SPDX to advance SBOM tooling and improve the quality of metadata. 

  

GUAC’s process for incorporating and enriching metadata for organizational insight

Consistent interfaces

Alongside the boom in SBOM production, there’s been a rapid expansion of new standards, document types, and formats, making it hard to perform consistent queries. The multiple formats for software supply chain metadata often refer to similar concepts, but with different terms. To integrate these, GUAC defines a common vocabulary for talking about the software supply chain—for example, artifacts, packages, repositories, and the relationships between them. 



This vocabulary is then exposed as a GraphQL API, empowering users to build powerful integrations on top of GUAC’s knowledge graph. For example, users are able to query seamlessly with the same commands across different SBOM formats like SPDX and CycloneDX. 



According to Ed Warnicke, Distinguished Engineer at Cisco Systems, “Supply chain security is increasingly about making sense of many different kinds of metadata from many different sources. GUAC knits all of that information together into something understandable and actionable.” 

Potential integrations

Based on these features, we envision potential integrations that users can build on top of GUAC in order to:

  • Create policies based on trust

  • Quickly react to security compromises 

  • Determine an upgrade plan in response to a security incident

  • Create visualizers for data explorations, CLI tools for large scale analysis and incident response, CI checks, IDE plugins to shift policy left, and more



Developers can also build data source integrations under GUAC to expand its coverage. The entire GUAC architecture is plug-and-play, so you can write data integrations to get:

  • Supply chain metadata from new sources like your preferred security vendors

  • Parsers to translate this metadata into the GUAC ontology

  • Database backends to store the GUAC data in either common databases or in organization-defined private data stores

GUAC’s GraphQL query API enables a diverse ecosystem of tooling



Dejan Bosanac, an engineer at Red Hat and an active contributor to the GUAC project, further described GUAC’s ingestion abilities, “With mechanisms to ingest and certify data from various sources and GraphQL API to later query those data, we see it as a good foundation for our current and future SSCS efforts. Being a true open source initiative with a welcoming community is just a plus.” 



Next steps

Google is committed to making GUAC the best metadata synthesis and aggregation tool for security professionals. GUAC contributors are excited to meet at our monthly community calls and look forward to seeing demos of new applications built with GUAC.



“At Kusari, we are proud to have joined forces with Google’s Open Source Security Team and the community to create and build GUAC,” says Tim Miller, CEO of Kusari. “With GUAC, we believe in the critical role it plays in safeguarding the software supply chain and we are dedicated to ensuring its success in the ecosystem.” 



Google is preparing SBOMs for consumption by the US Federal Government following EO 14028, and we are internally ingesting our SBOM catalog into GUAC to gather early insights. We encourage you to do the same with the GUAC release and submit your feedback. If the API is not flexible enough, please let us know how we can extend it. You can also submit suggestions and feedback on GUAC development or use cases, either by emailing guac-maintainers@googlegroups.com or filing an issue on our GitHub repository.



We hope you’ll join us in this journey with GUAC!

/by

Digital security for the self‑employed: Staying safe without an IT team to help

Nobody wants to spend their time dealing with the fallout of a security incident instead of building up their business

The post Digital security for the self‑employed: Staying safe without an IT team to help appeared first on WeLiveSecurity

/by

How the Chrome Root Program Keeps Users Safe

Posted by Chrome Root Program, Chrome Security Team

What is the Chrome Root Program?

A root program is one of the foundations for securing connections to websites. The Chrome Root Program was announced in September 2022. If you missed it, don’t worry – we’ll give you a quick summary below!

Chrome Root Program: TL;DR

Chrome uses digital certificates (often referred to as “certificates,” “HTTPS certificates,” or “server authentication certificates”) to ensure the connections it makes for its users are secure and private. Certificates are issued by trusted entities called “Certification Authorities” (CAs). The collection of digital certificates, CA systems, and other related online services is the foundation of HTTPS and is often referred to as the “Web PKI.”

Before issuing a certificate to a website, the CA must verify that the certificate requestor legitimately controls the domain whose name will be represented in the certificate. This process is often referred to as “domain validation” and there are several methods that can be used. For example, a CA can specify a random value to be placed on a website, and then perform a check to verify the value’s presence. Typically, domain validation practices must conform with a set of security requirements described in both industry-wide and browser-specific policies, like the CA/Browser Forum “Baseline Requirements” and the Chrome Root Program policy.

Upon connecting to a website, Chrome verifies that a recognized (i.e., trusted) CA issued its certificate, while also performing additional evaluations of the connection’s security properties (e.g., validating data from Certificate Transparency logs). Once Chrome determines that the certificate is valid, Chrome can use it to establish an encrypted connection to the website. Encrypted connections prevent attackers from being able to intercept (i.e., eavesdrop) or modify communication. In security speak, this is known as confidentiality and integrity.

The Chrome Root Program, led by members of the Chrome Security team, provides governance and security review to determine the set of CAs trusted by default in Chrome. This set of so-called “root certificates” is known at the Chrome Root Store.

How does the Chrome Root Program keep users safe?

The Chrome Root Program keeps users safe by ensuring the CAs Chrome trusts to validate domains are worthy of that trust. We do that by:

  • administering policy and governance activities to manage the set of CAs trusted by default in Chrome,
  • evaluating impact and corresponding security implications related to public security incident disclosures by participating CAs, and
  • leading positive change to make the ecosystem more resilient.

Policy and Governance

The Chrome Root Program policy defines the minimum requirements a CA owner must meet for inclusion in the Chrome Root Store. It incorporates the industry-wide CA/Browser Forum Baseline Requirements and further adds security controls to improve Chrome user security.

The CA application process includes a public discussion phase, where members of the Web PKI community are free to raise well-founded, fact-based concerns related to an applicant on an open discussion forum.

We consider public discussion valuable because it:

  • improves security, transparency, and interoperability, and
  • highlights concerning behavior, practices, or ownership background information not readily available through public audits, policy reviews, or other application process inputs.

For a CA owner’s inclusion request to be accepted, it must clearly demonstrate that the value proposition for the security and privacy of Chrome’s end users exceeds the corresponding risk of inclusion.

Once a CA is trusted, it can issue certificates for any website on the internet; thus, each newly added CA represents an additional attack surface, and the Web PKI is only as safe as its weakest link. For example, in 2011 a compromised CA led to a large-scale attack on web users in Iran.

Incident Management

No CA is perfect. When a CA owner violates the Chrome Root Program policy – or experiences any other situation that affects the CA’s integrity, trustworthiness, or compatibility – we call it an incident. Incidents can happen. They are an expected part of building a secure Web PKI. All the same, incidents represent opportunities to improve practices, systems, and understanding. Our program is committed to continuous improvement and participates in a public Web PKI incident management process.

When incidents occur, we expect CA owners to identify the root cause and remediate it to help prevent similar incidents from happening again. CA owners record the incident in a report that the Chrome Root Program and the public can review, which encourages an understanding of all contributing factors to reduce the probability of its reoccurrence in the Web PKI.

The Chrome Root Program prioritizes the security and privacy of its users and is unwilling to compromise on these values. In rare cases, incidents may result in the Chrome Root Program losing confidence in the CA owner’s ability to operate securely and reliably. This may happen when there is evidence of a CA owner:

  • knowingly violating requirements or obfuscating incidents,
  • demonstrating sustained patterns of failure, untimely and opaque communications, or an unwillingness to improve elements that are critical to security, or
  • performing other actions that negatively impact or otherwise degrade the security of the Web.

In these cases, Chrome may distrust a CA – that is, remove the CA from the Chrome Root Store. Depending on the circumstance, Chrome may also block the certificate with a non-bypassable error page.

The above cases are only illustrative, and considerations for CA distrust are not limited to these examples. The Chrome Root Program may remove certificates from the Chrome Root Store, as it deems appropriate and at its sole discretion, to enhance security and promote interoperability in Chrome.

Positive Ecosystem Change

The Chrome Root Program collaborates with members of the Web PKI ecosystem in various forums (e.g., the CA/Browser Forum) and committees (e.g., the CCADB Steering Committee). We share best practices, advocate for and develop new standards to promote user security, and seek ecosystem participant feedback on proposed initiatives. Collectively, ecosystem participants contributing to these working groups are protecting the Web.

In June 2022, we announced the “Moving Forward, Together” initiative that shared our vision of the future Web PKI that includes modern, reliable, agile, and purpose-driven architectures with a focus on automation, simplicity, and security. The initiative represents the goals and priorities of the Chrome Root Program and reinforces our commitment to working alongside CA owners to make the Web a safer place.

Some of our current priorities include:

  • reducing misissuance of certificates that do not comply with the Baseline Requirements, a CA’s own policies, or the Chrome Root Program policy,
  • increasing accountability and ecosystem integrity with high-quality, independent audits,
  • automating certificate issuance and strengthening the domain validation process, and
  • preparing for a “post-quantum” world.

We believe implementing proposals related to these priorities will help manage risk and make the Web a safer place for everyone.

However, as the name suggests, we can only realize these opportunities to improve with the collective contributions of the community. We understand CAs to be an essential element of the Web PKI, and we are encouraged by continued feedback and participation from existing and future CA owners in our program.

The Chrome Root Program is committed to openness and transparency, and we are optimistic we can achieve this shared vision. If you’re interested in seeing what new initiatives are being explored by the Chrome Root Program to keep Chrome users safe – you can learn more here.

/by

Android app breaking bad: From legitimate screen recording to file exfiltration within a year

ESET researchers discover AhRat – a new Android RAT based on AhMyth – that exfiltrates files and records audio

The post Android app breaking bad: From legitimate screen recording to file exfiltration within a year appeared first on WeLiveSecurity

/by

The real cost of a free lunch – Week in security with Tony Anscombe

Don’t download software from non-reputable websites and sketchy links – you might be in for more than you bargained for

The post The real cost of a free lunch – Week in security with Tony Anscombe appeared first on WeLiveSecurity

/by

5 useful search engines for internet‑connected devices and services

A roundup of some of the handiest tools that security professionals can use to search for and monitor devices that are accessible from the internet

The post 5 useful search engines for internet‑connected devices and services appeared first on WeLiveSecurity

/by

New Android & Google Device Vulnerability Reward Program Initiatives

Posted by Sarah Jacobus, Vulnerability Rewards Team

As technology continues to advance, so do efforts by cybercriminals who look to exploit vulnerabilities in software and devices. This is why at Google and Android, security is a top priority, and we are constantly working to make our products more secure. One way we do this is through our Vulnerability Reward Programs (VRP), which incentivize security researchers to find and report vulnerabilities in our operating system and devices.

We are pleased to announce that we are implementing a new quality rating system for security vulnerability reports to encourage more security research in higher impact areas of our products and ensure the security of our users. This system will rate vulnerability reports as High, Medium, or Low quality based on the level of detail provided in the report. We believe that this new system will encourage researchers to provide more detailed reports, which will help us address reported issues more quickly and enable researchers to receive higher bounty rewards.

The highest quality and most critical vulnerabilities are now eligible for larger rewards of up to $15,000!

There are a few key elements we are looking for:

Accurate and detailed description: A report should clearly and accurately describe the vulnerability, including the device name and version. The description should be detailed enough to easily understand the issue and begin working on a fix.

Root cause analysis: A report should include a full root cause analysis that describes why the issue is occurring and what Android source code should be patched to fix it. This analysis should be thorough and provide enough information to understand the underlying cause of the vulnerability.


Proof-of-concept: A report should include a proof-of-concept that effectively demonstrates the vulnerability. This can include video recordings, debugger output, or other relevant information. The proof-of-concept should be of high quality and include the minimum amount of code possible to demonstrate the issue.

Reproducibility: A report should include a step-by-step explanation of how to reproduce the vulnerability on an eligible device running the latest version. This information should be clear and concise and should allow our engineers to easily reproduce the issue and begin working on a fix.

Evidence of reachability: Finally, a report should include evidence or analysis that demonstrates the type of issue and the level of access or execution achieved.

*Note: This criteria may change over time. For the most up to date information, please refer to our public rules page.

Additionally, starting March 15th, 2023, Android will no longer assign Common Vulnerabilities and Exposures (CVEs) to most moderate severity issues. CVEs will continue to be assigned to critical and high severity vulnerabilities.

We believe that incentivizing researchers to provide high-quality reports will benefit both the broader security community and our ability to take action. We look forward to continuing to work with researchers to make the Android ecosystem more secure.

If you would like more information on the Android & Google Device Vulnerability Reward Program, please visit our public rules page to learn more!

/by