What's new arround internet
| Src | Date (GMT) | Titre | Description | Tags | Stories | Notes |
 |
2023-03-01 11:59:44 | 8 ways to secure Chrome browser for Google Workspace users (lien direct) | Posted by Kiran Nair, Product Manager, Chrome Browser Your journey towards keeping your Google Workspace users and data safe, starts with bringing your Chrome browsers under Cloud Management at no additional cost. Chrome Browser Cloud Management is a single destination for applying Chrome Browser policies and security controls across Windows, Mac, Linux, iOS and Android. You also get deep visibility into your browser fleet including which browsers are out of date, which extensions your users are using and bringing insight to potential security blindspots in your enterprise. Managing Chrome from the cloud allows Google Workspace admins to enforce enterprise protections and policies to the whole browser on fully managed devices, which no longer requires a user to sign into Chrome to have policies enforced. You can also enforce policies that apply when your managed users sign in to Chrome browser on any Windows, Mac, or Linux computer (via Chrome Browser user-level management) --not just on corporate managed devices.  This enables you to keep your corporate data and users safe, whether they are accessing work resources from fully managed, personal, or unmanaged devices used by your vendors. Getting started is easy. If your organization hasn't already, check out this guide for steps on how to enroll your devices. 2. Enforce built-in protections against Phishing, Ransomware & Malware Chrome uses Google's Safe Browsing technology to help protect billions of devices every day by showing warnings to users when they attempt to navigate to dangerous sites or download dangerous files. Safe Browsing is enabled by default for all users when they download Chrome. As an administrator, you can prevent your users from disabling Safe Browsing by enforcing the SafeBrowsingProtectionLevel policy.  Over the past few years, we've seen threats on the web becoming increasingly sophisticated. Turning on Enhanced Safe Browsing will substantially increase protection |
Ransomware Malware Tool Threat Guideline Cloud | ★★★ | |
|
2023-02-28 09:00:14 | Our commitment to fighting invalid traffic on Connected TV (lien direct) | Posted by Michael Spaulding, Senior Product Manager, Ad Traffic QualityConnected TV (CTV) has not only transformed the entertainment world, it has also created a vibrant new platform for digital advertising. However, as with any innovative space, there are challenges that arise, including the emergence of bad actors aiming to siphon money away from advertisers and publishers through fraudulent or invalid ad traffic. Invalid traffic is an evolving challenge that has the potential to affect the integrity and health of digital advertising on CTV. However, there are steps the industry can take to combat invalid traffic and foster a clean, trustworthy, and sustainable ecosystem.Information sharing and following best practicesEvery player across the digital advertising ecosystem has the opportunity to help reduce the risk of CTV ad fraud. It starts by spreading awareness across the industry and building a commitment among partners to share best practices for defending against invalid traffic. Greater transparency and communication are crucial to creating lasting solutions.One key best practice is contributing to and using relevant industry standards. We encourage CTV inventory providers to follow the CTV/OTT Device & App Identification Guidelines and IFA Guidelines. These guidelines, both of which were developed by the IAB Tech Lab, foster greater transparency, which in turn reduces the risk of invalid traffic on CTV. More information and details about using these resources can be found in the following guide: Protecting your ad-supported CTV experiences.Collaborating on standards and solutionsNo single company or industry group can solve this challenge on their own, we need to work collaboratively to solve the problem. Fortunately, we're already seeing constructive efforts in this direction with industry-wide standards.For example, the broad implementation of the IAB Tech Lab's app-ads.txt and its web counterpart, ads.txt, have brought greater transparency to the digital advertising supply chain and have helped combat ad fraud by allowing advertisers to verify the sellers from whom they buy inventory. In 2021, the IAB Tech Lab extended the app-ads.txt standard to CTV in order to better protect and support CTV advertisers. This update is the first of several industry-wide steps that have been taken to further protect CTV advertising. In early 2022, the IAB Tech Lab released the ads.cert 2.0 “protocol suite,” along with a proposal to utilize this new standard to secure server-side connections (including for server-side ad insertion). Ads.cert 2.0 will also power future industry standards focused on securing the supply chain and preventing misrepresentation.In addition to these efforts, the Media Rating Council (MRC) also engaged with stakeholders to develop its | Guideline | ★★★ | |
|
2023-02-22 12:01:42 | Vulnerability Reward Program: 2022 Year in Review (lien direct) | Posted by Sarah Jacobus, Vulnerability Rewards Team It has been another incredible year for the Vulnerability Reward Programs (VRPs) at Google! Working with security researchers throughout 2022, we have been able to identify and fix over 2,900 security issues and continue to make our products more secure for our users around the world. We are thrilled to see significant year over year growth for our VRPs, and have had yet another record breaking year for our programs! In 2022 we awarded over $12 million in bounty rewards – with researchers donating over $230,000 to a charity of their choice. As in past years, we are sharing our 2022 Year in Review statistics across all of our programs. We would like to give a special thank you to all of our dedicated researchers for their continued work with our programs - we look forward to more collaboration in the future!   AndroidThe Android VRP had an incredible record breaking year in 2022 with $4.8 million in rewards and the highest paid report in Google VRP history of $605,000! In our continued effort to ensure the security of Google device users, we have expanded the scope of Android and Google Devices in our program and are now incentivizing vulnerability research in the latest versions of Google Nest and Fitbit! For more information on the latest program version and qualifying vulnerability reports, please visit our public rules page. We are also excited to share that the invite-only Android Chipset Security Reward Program (ACSRP) - a private vulnerability reward program offered by Google in collaboration with manufacturers of Android chipsets - rewarded $486,000 in 2022 and received over 700 valid security reports. We would like to give a special shoutout to some of our top researchers, whose continued hard work helps to keep Android safe and secure: Submitting an impressive 200+ vulnerabilities to the Android VRP this year, Aman Pandey of Bugsmirror remains one of our program's top researchers. Since submitting their first report in 2019, Aman has reported more than 500 vulnerabilities to the program. Their hard work helps ensure the safety of our users; a huge thank you for all of their hard work! Zinuo Han of OPPO Amber Security Lab |
Vulnerability Guideline | ★★ | |
|
2022-12-15 20:51:24 | Expanding the App Defense Alliance (lien direct) | Posted by Brooke Davis, Android Security and Privacy Team The App Defense Alliance launched in 2019 with a mission to protect Android users from bad apps through shared intelligence and coordinated detection between alliance partners. Earlier this year, the App Defense Alliance expanded to include new initiatives outside of malware detection and is now the home for several industry-led collaborations including Malware Mitigation, MASA (Mobile App Security Assessment) & CASA (Cloud App Security Assessment). With a new dedicated landing page at appdefensealliance.dev, the ADA has an expanded mission to protect Android users by removing threats while improving app quality across the ecosystem. Let's walk through some of the latest program updates from the past year, including the addition of new ADA members. Malware MitigationTogether, with the founding ADA members - Google, ESET, Lookout, and Zimperium, the alliance has been able to reduce the risk of app-based malware and better protect Android users. These partners have access to mobile apps as they are being submitted to the Google Play Store and scan thousands of apps daily, acting as another, vital set of eyes prior to an app going live on Play. Knowledge sharing and industry collaboration are important aspects in securing the world from attacks and that's why we're continuing to invest in the program. New ADA MembersWe're excited to see the ADA expand with the additions of McAfee and Trend Micro. Both McAfee and Trend Micro are leaders in the antivirus space and we look forward to their contributions to the program. Mobile App Security Assessment (MASA)With consumers spending four to five hours per day in mobile apps, ensuring the safety of these services is more important than ever. According to Data.ai, the pandemic accelerated existing mobile habits - with app categories like finance growing 25% YoY and users spending over 100 billion hours in shopping apps. That's why the ADA introduced MASA (Mobile App Security Assessment), which allows developers to have their apps independently validated against the Mobile Application Security Verification Standard (MASVS standard) under the OWASP Mobile Application Security project. The project's mission is to “Define the industry standard for mobile application security,” and has been used by both public and private sector organizations as a form of industry best practices when it comes to mobile application security. Developers can work directly with an ADA Authorized Lab to have their apps evaluated against a set of MASVS L1 requirements. Once successful, the app's validation is listed in the recently launched App Validation Directory, which provides users a single place to view all app validations. The Directory also allows users to access more assessment details including validation date, test lab, and a report showing all test steps and requirements. The Directory will be updated over time with new features and search functionality to make it more user friendly. The Google Play Store is the first commercial app store to recognize and display a badge for any app that has completed an independent security review through ADA MASA. The badge is displayed within an app's respective | Malware Guideline Prediction | Uber | ★★ |
|
2022-11-02 14:12:24 | Our Principles for IoT Security Labeling (lien direct) | Posted by Dave Kleidermacher, Eugene Liderman, and Android and Made by Google security teams We believe that security and transparency are paramount pillars for electronic products connected to the Internet. Over the past year, we've been excited to see more focused activity across policymakers, industry partners, developers, and public interest advocates around raising the security and transparency bar for IoT products. That said, the details of IoT product labeling - the definition of labeling, what labeling needs to convey in terms of security and privacy, where the label should reside, and how to achieve consumer acceptance, are still open for debate. Google has also been considering these core questions for a long time. As an operating system, IoT product provider, and the maintainer of multiple large ecosystems, we see firsthand how critical these details will be to the future of the IoT. In an effort to be a catalyst for collaboration and transparency, today we're sharing our proposed list of principles around IoT security labeling. Setting the Stage: Defining IoT Labeling IoT labeling is a complex and nuanced topic, so as an industry, we should first align on a set of labeling definitions that could help reduce potential fragmentation and offer a harmonized approach that could drive a desired outcome: Label: printed and/or digital representation of a digital product's security and/or privacy status intended to inform consumers and/or other stakeholders. A label may include both printed and digital representations; for example, a printed label may include a logo and QR code that references a digital representation of the security claims being made. Labeling scheme: a program that defines, manages, and monitors the use of labels, including but not limited to user experience, adherence to specific standards or security profiles, and lifecycle management of the label (e.g. decommissioning) Evaluation scheme: a program that publishes, manages, and monitors the security claims of digital products against security requirements and related standards; labeling schemes may rely on evaluation schemes to produce the information referred to in or by their labels. Proposed Principles for IoT Security Labeling SchemesWe believe in five core principles for IoT labeling schemes. These principles will help increase transparency against the full baseline of security criteria for IoT. These principles will also increase competition in security and push manufacturers to offer products with effective security protections, increase transparency, and help generate higher levels of assurance of protection over time. 1. A printed label must not imply trustUnlike food labels, digital security labels must be “live” labels, where security/privacy status is conveyed on a central maintained website, which ideally would be the same site hosting the evaluation scheme. A physical label, either printed on a box or visible in an app, can be used if and only if it encourages users to visit the website (e.g. scan a QR code or click a link) to obtain the real-time status. At any point in time, a digital product may become unsafe for use. For example, if a critical, in-the-wild, remote exploit of a product is discovered and cannot be mitigated (e.g. via a patch), then it may be necessary to change that product's status from safe to unsafe. Printed labels, if they convey trust implicitly such as, “certified to NNN standard” or, “3 stars”, run the danger of influencing consumers to make harmful decisions. A consumer may purchase a webcam with a “3-star” security label only to find when they return home the product has non-mitigatable vulnerabiliti | Vulnerability Threat Guideline | ||
|
2022-10-12 08:00:03 | Security of Passkeys in the Google Password Manager (lien direct) | Posted by Arnar Birgisson, Software EngineerWe are excited to announce passkey support on Android and Chrome for developers to test today, with general availability following later this year. In this post we cover details on how passkeys stored in the Google Password Manager are kept secure. See our post on the Android Developers Blog for a more general overview.Passkeys are a safer and more secure alternative to passwords. They also replace the need for traditional 2nd factor authentication methods such as text message, app based one-time codes or push-based approvals. Passkeys use public-key cryptography so that data breaches of service providers don't result in a compromise of passkey-protected accounts, and are based on industry standard APIs and protocols to ensure they are not subject to phishing attacks.Passkeys are the result of an industry-wide effort. They combine secure authentication standards created within the FIDO Alliance and the W3C Web Authentication working group with a common terminology and user experience across different platforms, recoverability against device loss, and a common integration path for developers. Passkeys are supported in Android and other leading industry client OS platforms.A single passkey identifies a particular user account on some online service. A user has different passkeys for different services. The user's operating systems, or software similar to today's password managers, provide user-friendly management of passkeys. From the user's point of view, using passkeys is very similar to using saved passwords, but with significantly better security.The main ingredient of a passkey is a cryptographic private key. In most cases, this private key lives only on the user's own devices, such as laptops or mobile phones. When a passkey is created, only its corresponding public key is stored by the online service. During login, the service uses the public key to verify a signature from the private key. This can only come from one of the user's devices. Additionally, the user is also required to unlock their device or credential store for this to happen, preventing sign-ins from e.g. a stolen phone. To address the common case of device loss or upgrade, a key feature enabled by passkeys is that the same private key can exist on multiple devices. This happens through platform-provided synchronization and backup. | Guideline | ||
|
2022-10-11 19:22:42 | Google Pixel 7 and Pixel 7 Pro: The next evolution in mobile security (lien direct) | Dave Kleidermacher, Jesse Seed, Brandon Barbello, Sherif Hanna, Eugene Liderman, Android, Pixel, and Silicon Security Teams Every day, billions of people around the world trust Google products to enrich their lives and provide helpful features – across mobile devices, smart home devices, health and fitness devices, and more. We keep more people safe online than anyone else in the world, with products that are secure by default, private by design and that put you in control. As our advancements in knowledge and computing grow to deliver more help across contexts, locations and languages, our unwavering commitment to protecting your information remains. That's why Pixel phones are designed from the ground up to help protect you and your sensitive data while keeping you in control. We're taking our industry-leading approach to security and privacy to the next level with Google Pixel 7 and Pixel 7 Pro, our most secure and private phones yet, which were recently recognized as the highest rated for security when tested among other smartphones by a third-party global research firm.1 Pixel phones also get better every few months with Feature Drops that provide the latest product updates, tips and tricks from Google. And Pixel 7 and Pixel 7 Pro users will receive at least five years of security updates2, so your Pixel gets even more secure over time. Your protection, built into PixelYour digital life and most sensitive information lives on your phone: financial information, passwords, personal data, photos – you name it. With Google Tensor G2 and our custom Titan M2 security chip, Pixel 7 and Pixel 7 Pro have multiple layers of hardware security to help keep you and your personal information safe. We take a comprehensive, end-to-end approach to security with verifiable protections at each layer - the network, application, operating system and multiple layers on the silicon itself. If you use Pixel for your business, this approach helps protect your company data, too.  Google Tensor G2 is Pixel's newest powerful processor custom built with Google AI, and makes Pixel 7 faster, more efficient and secure3. Every aspect of Tensor G2 was designed to improve Pixel's performance and efficiency for great battery life, amazing photos and videos. Tensor's built-in security core works with our Titan M2 security chip to keep your personal information, PINs and passwords safe. Titan family chips are also used to protect Google Cloud data centers and Chromebooks, so the same hardware that protects Google servers also secures your sensitive information stored on Pixel. And, in a first for Google, Titan M2 hardware has now been certified under Common Criteria PP0084: the international gold standard for hardware security components also used for identity, SIM cards, and bankcard security chips. |
Spam Malware Vulnerability Guideline Industrial | APT 40 | |
|
2022-09-13 12:59:14 | Use-after-freedom: MiraclePtr (lien direct) | Posted by Adrian Taylor, Bartek Nowierski and Kentaro Hara on behalf of the MiraclePtr team Memory safety bugs are the most numerous category of Chrome security issues and we're continuing to investigate many solutions – both in C++ and in new programming languages. The most common type of memory safety bug is the “use-after-free”. We recently posted about an exciting series of technologies designed to prevent these. Those technologies (collectively, *Scan, pronounced “star scan”) are very powerful but likely require hardware support for sufficient performance. Today we're going to talk about a different approach to solving the same type of bugs. It's hard, if not impossible, to avoid use-after-frees in a non-trivial codebase. It's rarely a mistake by a single programmer. Instead, one programmer makes reasonable assumptions about how a bit of code will work, then a later change invalidates those assumptions. Suddenly, the data isn't valid as long as the original programmer expected, and an exploitable bug results. These bugs have real consequences. For example, according to Google Threat Analysis Group, a use-after-free in the ChromeHTML engine was exploited this year by North Korea. Half of the known exploitable bugs in Chrome are use-after-frees:  Diving Deeper: Not All Use-After-Free Bugs Are Equal Chrome has a multi-process architecture, partly to ensure that web content is isolated into a sandboxed “renderer” process where little harm can occur. An attacker therefore usually needs to find and exploit two vulnerabilities - one to achieve code execution in the renderer process, and another bug to break out of the sandbox. The first stage is often the easier one. The attacker has lots of influence in the renderer process. It's easy to arrange memory in a specific way, and the renderer process acts upon many different kinds of web content, giving a large “attack surface” that could potentially be exploited. The second stage, escaping the renderer sandbox, is trickier. Attackers have two options how to do this: They can exploit a bug in the underlying operating system (OS) through the limited interfaces available inside Chrome's sandbox. Or, they can exploit a bug in a more powerful, privileged part of Chrome - like the “browser” process. This process coordinates all the other bits of Chrome, so fundamentally has to be all-powerful. We imagine the attackers squeezing through the narrow part of a funnel: |
Vulnerability Threat Guideline | ||
|
2022-08-30 07:15:00 | Announcing Google\'s Open Source Software Vulnerability Rewards Program (lien direct) | Posted by Francis Perron, Open Source Security Technical Program ManagerToday, we are launching Google's Open Source Software Vulnerability Rewards Program (OSS VRP) to reward discoveries of vulnerabilities in Google's open source projects. As the maintainer of major projects such as Golang, Angular, and Fuchsia, Google is among the largest contributors and users of open source in the world. With the addition of Google's OSS VRP to our family of Vulnerability Reward Programs (VRPs), researchers can now be rewarded for finding bugs that could potentially impact the entire open source ecosystem.Google has been committed to supporting security researchers and bug hunters for over a decade. The original VRP program, established to compensate and thank those who help make Google's code more secure, was one of the first in the world and is now approaching its 12th anniversary. Over time, our VRP lineup has expanded to include programs focused on Chrome, Android, and other areas. Collectively, these programs have rewarded more | Vulnerability Guideline | ||
|
2022-08-08 11:59:54 | How Hash-Based Safe Browsing Works in Google Chrome (lien direct) | By Rohit Bhatia, Mollie Bates, Google Chrome Security There are various threats a user faces when browsing the web. Users may be tricked into sharing sensitive information like their passwords with a misleading or fake website, also called phishing. They may also be led into installing malicious software on their machines, called malware, which can collect personal data and also hold it for ransom. Google Chrome, henceforth called Chrome, enables its users to protect themselves from such threats on the internet. When Chrome users browse the web with Safe Browsing protections, Chrome uses the Safe Browsing service from Google to identify and ward off various threats. Safe Browsing works in different ways depending on the user's preferences. In the most common case, Chrome uses the privacy-conscious Update API (Application Programming Interface) from the Safe Browsing service. This API was developed with user privacy in mind and ensures Google gets as little information about the user's browsing history as possible. If the user has opted-in to "Enhanced Protection" (covered in an earlier post) or "Make Searches and Browsing Better", Chrome shares limited additional data with Safe Browsing only to further improve user protection. This post describes how Chrome implements the Update API, with appropriate pointers to the technical implementation and details about the privacy-conscious aspects of the Update API. This should be useful for users to understand how Safe Browsing protects them, and for interested developers to browse through and understand the implementation. We will cover the APIs used for Enhanced Protection users in a future post. Threats on the Internet When a user navigates to a webpage on the internet, their browser fetches objects hosted on the internet. These objects include the structure of the webpage (HTML), the styling (CSS), dynamic behavior in the browser (Javascript), images, downloads initiated by the navigation, and other webpages embedded in the main webpage. These objects, also called resources, have a web address which is called their URL (Uniform Resource Locator). Further, URLs may redirect to other URLs when being loaded. Each of these URLs can potentially host threats such as phishing websites, malware, unwanted downloads, malicious software, unfair billing practices, and more. Chrome with Safe Browsing checks all URLs, redirects or included resources, to identify such threats and protect users. Safe Browsing Lists Safe Browsing provides a list for each threat it protects users against on the internet. A full catalog of lists that are used in Chrome can be found by visiting chrome://safe-browsing/#tab-db-manager on desktop platforms. A list does not contain unsafe web addresses, also referred to as URLs, in entirety; it would be prohibitively expensive to keep all of them in a device's limited memory. Instead it maps a URL, which can be very long, through a cryptographic hash function (SHA-256), to a unique fixed size string. This distinct fixed size string, called a hash, allows a list to be stored efficiently in limited memory. The Update API handles URLs only in the form of hashes and is also called hash-based API in this post. Further, a list does not store hashes in entirety either, as even that would be too memory intensive. Instead, barring a case where data is not shared with Google and the list is small, it contains prefixes of the hashes. We refer to the original hash as a full hash, and | Malware Threat Guideline | ||
|
2022-07-12 13:11:21 | TAG Bulletin: Q2 2022 (lien direct) | Posted by Shane Huntley, Director, Threat Analysis GroupThis bulletin includes coordinated influence operation campaigns terminated on our platforms in Q2 2022. It was last updated on June 30, 2022.MayWe terminated 20 YouTube channels as part of our investigation into coordinated influence operations linked to Russia. The campaign was linked to a Russian consulting firm and was sharing content in Russian that was supportive of Russia's actions in Ukraine and Russian President Vladimir Putin and critical of NATO, Ukraine, and Ukrainian President Volodymyr Zelenskyy.We terminated 5 YouTube channels, 1 AdSense account, and 1 Blogger blog as part of our investigation into coordinated influence operations linked to Russia. The campaign was linked to Russian state-sponsored entities and was sharing content in Russian and Bulgarian that was supportive of separatist movements in the disputed regions of Ukraine and critical of Ukraine and the West.We terminated 14 YouTube channels as part of our investigation into coordinated influence operations linked to Russia. The campaign was linked to the Internet Research Agency (IRA) and was sharing content in Russian that was critical of Ukrainian politicians.We blocked 1 domain from eligibility to appear on Google News surfaces and Discover as part of our investigation into coordinated influence operations linked to Iran. The campaign was linked to Endless Mayfly and was sharing content in English about a variety of topics including US and global current events. We received leads from Mandiant that supported us in this investigation. | Threat Guideline | ||
|
2022-05-26 13:53:04 | Retrofitting Temporal Memory Safety on C++ (lien direct) | Posted by Anton Bikineev, Michael Lippautz and Hannes Payer, Chrome security teamMemory safety in Chrome is an ever-ongoing effort to protect our users. We are constantly experimenting with different technologies to stay ahead of malicious actors. In this spirit, this post is about our journey of using heap scanning technologies to improve memory safety of C++.Let's start at the beginning though. Throughout the lifetime of an application its state is generally represented in memory. Temporal memory safety refers to the problem of guaranteeing that memory is always accessed with the most up to date information of its structure, its type. C++ unfortunately does not provide such guarantees. While there is appetite for different languages than C++ with stronger memory safety guarantees, large codebases such as Chromium will use C++ for the foreseeable future.auto* foo = new Foo();delete foo | Tool Guideline | ||
|
2022-04-12 17:47:40 | Vulnerability Reward Program: 2021 Year in Review (lien direct) | Posted by Sarah Jacobus, Vulnerability Rewards Team Last year was another record setter for our Vulnerability Reward Programs (VRPs). Throughout 2021, we partnered with the security researcher community to identify and fix thousands of vulnerabilities – helping keep our users and the internet safe. Thanks to these incredible researchers, Vulnerability Reward Programs across Google continued to grow, and we are excited to report that in 2021 we awarded a record breaking $8,700,000 in vulnerability rewards – with researchers donating over $300,000 of their rewards to a charity of their choice. We also launched bughunters.google.com in 2021, a public researcher portal dedicated to keeping Google products and the internet safe and secure. This new platform brings all of our VRPs (Google, Android, Abuse, Chrome, and Google Play) closer together and provides a single intake form, making security bug submission easier than ever. We're excited about everything the new Bug Hunters portal has to offer, including:More opportunities for interaction and a bit of healthy competition through gamification, per-country leaderboards, awards/badges for certain bugs, and more!A more functional and aesthetically pleasing leaderboard. We know a lot of you are using your achievements in our VRPs to find jobs (we're hiring!) and we hope this acts as a useful resource.A stronger emphasis on learning: bug hunters can improve their skills through the content available in our new | Vulnerability Guideline |
1
We have: 13 articles.
We have: 13 articles.
To see everything:
Our RSS (filtrered)
