What's new arround internet
Last one

Src Date (GMT) Titre Description Tags Stories Notes
GoogleSec.webp 2024-05-15 12:59:21 E / S 2024: Ce qui est nouveau dans la sécurité et la confidentialité d'Android
I/O 2024: What\\'s new in Android security and privacy (lien direct)		 Posted by Dave Kleidermacher, VP Engineering, Android Security and Privacy Our commitment to user safety is a top priority for Android. We\'ve been consistently working to stay ahead of the world\'s scammers, fraudsters and bad actors. And as their tactics evolve in sophistication and scale, we continually adapt and enhance our advanced security features and AI-powered protections to help keep Android users safe. In addition to our new suite of advanced theft protection features to help keep your device and data safe in the case of theft, we\'re also focusing increasingly on providing additional protections against mobile financial fraud and scams. Today, we\'re announcing more new fraud and scam protection features coming in Android 15 and Google Play services updates later this year to help better protect users around the world. We\'re also sharing new tools and policies to help developers build safer apps and keep their users safe. Google Play Protect live threat detection Google Play Protect now scans 200 billion Android apps daily, helping keep more than 3 billion users safe from malware. We are expanding Play Protect\'s on-device AI capabilities with Google Play Protect live threat detection to improve fraud and abuse detection against apps that try to cloak their actions. With live threat detection, Google Play Protect\'s on-device AI will analyze additional behavioral signals related to the use of sensitive permissions and interactions with other apps and services. If suspicious behavior is discovered, Google Play Protect can send the app to Google for additional review and then warn users or disable the app if malicious behavior is confirmed. The detection of suspicious behavior is done on device in a privacy preserving way through Private Compute Core, which allows us to protect users without collecting data. Google Pixel, Honor, Lenovo, Nothing, OnePlus, Oppo, Sharp, Transsion, and other manufacturers are deploying live threat detection later this year. Stronger protections against fraud and scams We\'re also bringing additional protections to fight fraud and scams in Android 15 with two key enhancements to safeguard your information and privacy from bad apps: Protecting One-time Passwords from Malware: With the exception of a few types of apps, such as wearable companion apps, one-time passwords are now hidden from notifications, closing a common attack vector for fraud and spyware. Expanded Restricted Settings: To help protect more sensitive permissions that are commonly abused by fraudsters, we\'re expanding Android 13\'s restricted settings, which require additional user approval to enable permissions when installing an app from an Internet-sideloading source (web browsers, messaging apps or file managers). We are continuing to develop new, AI-powered protections, Malware Tool Threat Mobile Cloud
GoogleSec.webp 2024-04-30 12:14:48 Détection du vol de données du navigateur à l'aide des journaux d'événements Windows
Detecting browser data theft using Windows Event Logs (lien direct)		 Publié par Will Harris, Chrome Security Team Le modèle de processus sandboxé de Chrome \\ de se défend bien contre le contenu Web malveillant, mais il existe des limites à la façon dont l'application peut se protéger des logiciels malveillants déjà sur l'ordinateur.Les cookies et autres informations d'identification restent un objectif de grande valeur pour les attaquants, et nous essayons de lutter contre cette menace continue de plusieurs manières, notamment en travaillant sur des normes Web comme dbsc Cela aidera à perturber l'industrie du vol de cookies car l'exfiltration de ces cookies n'aura plus de valeur. Lorsqu'il n'est pas possible d'éviter le vol d'identification et de cookies par malware, la prochaine meilleure chose est de rendre l'attaque plus observable par antivirus, d'agents de détection de terminaux ou d'administrateurs d'entreprise avec des outils d'analyse de journaux de base. Ce blog décrit un ensemble de signaux à utiliser par les administrateurs système ou les agents de détection de point de terminaison qui devraient signaler de manière fiable tout accès aux données protégées du navigateur d'une autre application sur le système.En augmentant la probabilité d'une attaque détectée, cela modifie le calcul pour les attaquants qui pourraient avoir un fort désir de rester furtif et pourraient les amener à repenser ces types d'attaques contre nos utilisateurs. arrière-plan Les navigateurs basés sur le chrome sur Windows utilisent le DPAPI (API de protection des données) pour sécuriser les secrets locaux tels que les cookies, le mot de passe, etc.La protection DPAPI est basée sur une clé dérivée des informations d'identification de connexion de l'utilisateur et est conçue pour se protéger contre l'accès non autorisé aux secrets des autres utilisateurs du système ou lorsque le système est éteint.Étant donné que le secret DPAPI est lié à l'utilisateur connecté, il ne peut pas protéger contre les attaques de logiciels malveillants locaux - l'exécution de logiciels malveillants en tant qu'utilisateur ou à un niveau de privilège plus élevé peut simplement appeler les mêmes API que le navigateur pour obtenir le secret DPAPI. Depuis 2013, Chromium applique l'indicateur CryptProtect_Audit aux appels DPAPI pour demander qu'un journal d'audit soit généré lorsque le décryptage se produit, ainsi que le marquage des données en tant que détenue par le navigateur.Parce que tout le stockage de données crypté de Chromium \\ est soutenu par une clé sécurisée DPAPI, toute application qui souhaite décrypter ces données, y compris les logiciels malveillants, devrait toujours générer de manière fiable un journal d'événements clairement observable, qui peut être utilisé pour détecter ces typesd'attaques. Il y a trois étapes principales impliquées dans le profit de ce journal: Activer la connexion sur l'ordinateur exécutant Google Chrome, ou tout autre navigateur basé sur le chrome. Exporter les journaux des événements vers votre système backend. Créer une logique de détection pour détecter le vol. Ce blog montrera également comment la journalisation fonctionne dans la pratique en la testant contre un voleur de mot de passe Python. Étape 1: Activer la connexion sur le système Les événements DPAPI sont connectés à deux endroits du système.Premièrement, il y a le 4693 Événement qui peut être connecté au journal de sécurité.Cet événement peut être activé en activant "Audit l'activité DPAPI" et les étapes pour ce faire sont d Malware Tool Threat ★★
GoogleSec.webp 2024-04-29 11:59:47 Comment nous avons combattu de mauvaises applications et de mauvais acteurs en 2023
How we fought bad apps and bad actors in 2023 (lien direct)		 Posted by Steve Kafka and Khawaja Shams (Android Security and Privacy Team), and Mohet Saxena (Play Trust and Safety) A safe and trusted Google Play experience is our top priority. We leverage our SAFE (see below) principles to provide the framework to create that experience for both users and developers. Here\'s what these principles mean in practice: (S)afeguard our Users. Help them discover quality apps that they can trust. (A)dvocate for Developer Protection. Build platform safeguards to enable developers to focus on growth. (F)oster Responsible Innovation. Thoughtfully unlock value for all without compromising on user safety. (E)volve Platform Defenses. Stay ahead of emerging threats by evolving our policies, tools and technology. With those principles in mind, we\'ve made recent improvements and introduced new measures to continue to keep Google Play\'s users safe, even as the threat landscape continues to evolve. In 2023, we prevented 2.28 million policy-violating apps from being published on Google Play1 in part thanks to our investment in new and improved security features, policy updates, and advanced machine learning and app review processes. We have also strengthened our developer onboarding and review processes, requiring more identity information when developers first establish their Play accounts. Together with investments in our review tooling and processes, we identified bad actors and fraud rings more effectively and banned 333K bad accounts from Play for violations like confirmed malware and repeated severe policy violations. Additionally, almost 200K app submissions were rejected or remediated to ensure proper use of sensitive permissions such as background location or SMS access. To help safeguard user privacy at scale, we partnered with SDK providers to limit sensitive data access and sharing, enhancing the privacy posture for over 31 SDKs impacting 790K+ apps. We also significantly expanded the Google Play SDK Index, which now covers the SDKs used in almost 6 million apps across the Android ecosystem. This valuable resource helps developers make better SDK choices, boosts app quality and minimizes integration risks. Protecting the Android Ecosystem Building on our success with the App Defense Alliance (ADA), we partnered with Microsoft and Meta as steering committee members in the newly restructured ADA under the Joint Development Foundation, part of the Linux Foundation family. The Alliance will support industry-wide adoption of app security best practices and guidelines, as well as countermeasures against emerging security risks. Additionally, we announced new Play Store transparency labeling to highlight VPN apps that have completed an independent security review through App Defense Alliance\'s Mobile App Security Assessment (MASA). When a user searches for VPN apps, they will now see a banner at the top of Google Play that educates them about the “Independent security review” badge in the Data safety section. This helps users see at-a-glance that a developer has prioritized security and privacy best practices and is committed to user safety. Malware Tool Threat Mobile ★★★
GoogleSec.webp 2024-04-26 18:33:10 Accélération de la réponse aux incidents en utilisant une AI générative
Accelerating incident response using generative AI (lien direct)		 Lambert Rosique and Jan Keller, Security Workflow Automation, and Diana Kramer, Alexandra Bowen and Andrew Cho, Privacy and Security Incident ResponseIntroductionAs security professionals, we\'re constantly looking for ways to reduce risk and improve our workflow\'s efficiency. We\'ve made great strides in using AI to identify malicious content, block threats, and discover and fix vulnerabilities. We also published the Secure AI Framework (SAIF), a conceptual framework for secure AI systems to ensure we are deploying AI in a responsible manner. Today we are highlighting another way we use generative AI to help the defenders gain the advantage: Leveraging LLMs (Large Language Model) to speed-up our security and privacy incidents workflows. Tool Threat Industrial Cloud ★★★
GoogleSec.webp 2024-04-08 14:12:48 Comment nous avons construit le nouveau réseau de recherche avec la sécurité des utilisateurs et la confidentialité
How we built the new Find My Device network with user security and privacy in mind (lien direct)		 Posted by Dave Kleidermacher, VP Engineering, Android Security and Privacy Keeping people safe and their data secure and private is a top priority for Android. That is why we took our time when designing the new Find My Device, which uses a crowdsourced device-locating network to help you find your lost or misplaced devices and belongings quickly – even when they\'re offline. We gave careful consideration to the potential user security and privacy challenges that come with device finding services. During development, it was important for us to ensure the new Find My Device was secure by default and private by design. To build a private, crowdsourced device-locating network, we first conducted user research and gathered feedback from privacy and advocacy groups. Next, we developed multi-layered protections across three main areas: data safeguards, safety-first protections, and user controls. This approach provides defense-in-depth for Find My Device users. How location crowdsourcing works on the Find My Device network The Find My Device network locates devices by harnessing the Bluetooth proximity of surrounding Android devices. Imagine you drop your keys at a cafe. The keys themselves have no location capabilities, but they may have a Bluetooth tag attached. Nearby Android devices participating in the Find My Device network report the location of the Bluetooth tag. When the owner realizes they have lost their keys and logs into the Find My Device mobile app, they will be able to see the aggregated location contributed by nearby Android devices and locate their keys. Find My Device network protections Let\'s dive into key details of the multi-layered protections for the Find My Device network: Data Safeguards: We\'ve implemented protections that help ensure the privacy of everyone participating in the network and the crowdsourced location data that powers it. Location data is end-to-end encrypted. When Android devices participating in the network report the location of a Bluetooth tag, the location is end-to-end encrypted using a key that is only a Vulnerability Threat Mobile ★★
GoogleSec.webp 2024-03-12 11:59:14 Programme de récompense de vulnérabilité: 2023 Année en revue
Vulnerability Reward Program: 2023 Year in Review (lien direct)		 Posted by Sarah Jacobus, Vulnerability Rewards Team Last year, we again witnessed the power of community-driven security efforts as researchers from around the world contributed to help us identify and address thousands of vulnerabilities in our products and services. Working with our dedicated bug hunter community, we awarded $10 million to our 600+ researchers based in 68 countries. New Resources and Improvements Just like every year, 2023 brought a series of changes and improvements to our vulnerability reward programs: Through our new Bonus Awards program, we now periodically offer time-limited, extra rewards for reports to specific VRP targets. We expanded our exploit reward program to Chrome and Cloud through the launch of v8CTF, a CTF focused on V8, the JavaScript engine that powers Chrome. We launched Mobile VRP which focuses on first-party Android applications. Our new Bughunters blog shared ways in which we make the internet, as a whole, safer, and what that journey entails. Take a look at our ever-growing repository of posts! To further our engagement with top security researchers, we also hosted our yearly security conference ESCAL8 in Tokyo. It included live hacking events and competitions, student training with our init.g workshops, and talks from researchers and Googlers. Stay tuned for details on ESCAL8 2024. As in past years, we are sharing our 2023 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! Android and Google Devices In 2023, the Android VRP achieved significant milestones, reflecting our dedication to securing the Android ecosystem. We awarded over $3.4 million in rewards to researchers who uncovered remarkable vulnerabilities within Android Vulnerability Threat Mobile Cloud Conference ★★★
GoogleSec.webp 2024-02-13 20:14:39 Piloter de nouvelles façons de protéger les utilisateurs d'Android contre la fraude financière
Piloting new ways of protecting Android users from financial fraud (lien direct)		 Posted by Eugene Liderman, Director of Mobile Security Strategy, Google From its founding, Android has been guided by principles of openness, transparency, safety, and choice. Android gives you the freedom to choose which device best fits your needs, while also providing the flexibility to download apps from a variety of sources, including preloaded app stores such as the Google Play Store or the Galaxy Store; third-party app stores; and direct downloads from the Internet.Keeping users safe in an open ecosystem takes sophisticated defenses. That\'s why Android provides multiple layers of protections, powered by AI and backed by a large dedicated security & privacy team, to help to protect our users from security threats while continually making the platform more resilient. We also provide our users with numerous built-in protections like Google Play Protect, the world\'s most widely deployed threat detection service, which actively scans over 125 billion apps on devices every day to monitor for harmful behavior. That said, our data shows that a disproportionate amount of bad actors take advantage of select APIs and distribution channels in this open ecosystem. Elevating app security in an open ecosystem While users have the flexibility to download apps from many sources, the safety of an app can vary depending on the download source. Google Play, for example, carries out rigorous operational reviews to ensure app safety, including proper high-risk API use and permissions handling. Other app stores may also follow established policies and procedures that help reduce risks to users and their data. These protections often include requirements for developers to declare which permissions their apps use and how developers plan to use app data. Conversely, standalone app distribution sources like web browsers, messaging apps or file managers – which we commonly refer to as Internet-sideloading – do not offer the same rigorous requirements and operational reviews. Our data demonstrates that users who download from these sources today face unusually high security risks due to these missing protections. We recently launched enhanced Google Play Protect real-time scanning to help better protect users against novel malicious Internet-sideloaded apps. This enhancement is designed to address malicious apps that leverage various methods, such as AI, to avoid detection. This feature, now deployed on Android devices with Google Play Services in India, Thailand, Singapore and Brazil, has already made a significant impact on user safety. As a result of the real-time scanning enhancement, Play Protect has identified 515,000 new malicious apps and issued more than 3.1 million warnings or blocks of those apps. Play Protect is constantly improving its detection capabilities with each identified app, allowing us to strengthen our protections for the entire Android ecosystem. A new pilot to combat financial fraud Cybercriminals continue to invest in advanced financial fraud scams, costing consumers more than $1 trillion in losses. According to the 2023 Global State of Scams Report by the Global Anti-Scam Alliance, 78 percent of mobile users surveyed experienced at least one scam in the last year. Of those surveyed, 45 percent said they\'re experiencing more scams in the last 12 months. The Global Scam Report also found that scams were most often initia Malware Threat Mobile ★★
GoogleSec.webp 2024-02-01 13:40:22 Le traité de la cybercriminalité des Nations Unies pourrait mettre en danger la sécurité du Web
UN Cybercrime Treaty Could Endanger Web Security (lien direct)		 Royal Hansen, Vice President of Privacy, Safety and Security EngineeringThis week, the United Nations convened member states to continue its years-long negotiations on the UN Cybercrime Treaty, titled “Countering the Use of Information and Communications Technologies for Criminal Purposes.” As more aspects of our lives intersect with the digital sphere, law enforcement around the world has increasingly turned to electronic evidence to investigate and disrupt criminal activity. Google takes the threat of cybercrime very seriously, and dedicates significant resources to combating it. When governments send Google legal orders to disclose user data in connection with their investigations, we carefully review those orders to make sure they satisfy applicable laws, international norms, and Google\'s policies. We also regularly report the number of these orders in our Transparency Report.  Threat ★★★
GoogleSec.webp 2024-01-11 14:18:14 MiraclePtr: protéger les utilisateurs contre les vulnérabilités sans utilisation sans plateformes
MiraclePtr: protecting users from use-after-free vulnerabilities on more platforms (lien direct)		 Posted by Keishi Hattori, Sergei Glazunov, Bartek Nowierski on behalf of the MiraclePtr team Welcome back to our latest update on MiraclePtr, our project to protect against use-after-free vulnerabilities in Google Chrome. If you need a refresher, you can read our previous blog post detailing MiraclePtr and its objectives. More platforms We are thrilled to announce that since our last update, we have successfully enabled MiraclePtr for more platforms and processes: In June 2022, we enabled MiraclePtr for the browser process on Windows and Android. In September 2022, we expanded its coverage to include all processes except renderer processes. In June 2023, we enabled MiraclePtr for ChromeOS, macOS, and Linux. Furthermore, we have changed security guidelines to downgrade MiraclePtr-protected issues by one severity level! Evaluating Security Impact First let\'s focus on its security impact. Our analysis is based on two primary information sources: incoming vulnerability reports and crash reports from user devices. Let\'s take a closer look at each of these sources and how they inform our understanding of MiraclePtr\'s effectiveness. Bug reports Chrome vulnerability reports come from various sources, such as: Chrome Vulnerability Reward Program participants, our fuzzing infrastructure, internal and external teams investigating security incidents. For the purposes of this analysis, we focus on vulnerabilities that affect platforms where MiraclePtr was enabled at the time the issues were reported. We also exclude bugs that occur inside a sandboxed renderer process. Since the initial launch of MiraclePtr in 2022, we have received 168 use-after-free reports matching our criteria. What does the data tell us? MiraclePtr effectively mitigated 57% of these use-after-free vulnerabilities in privileged processes, exceeding our initial estimate of 50%. Reaching this level of effectiveness, however, required additional work. For instance, we not only rewrote class fields to use MiraclePtr, as discussed in the previous post, but also added MiraclePtr support for bound function arguments, such as Unretained pointers. These pointers have been a significant source of use-after-frees in Chrome, and the additional protection allowed us to mitigate 39 more issues. Moreover, these vulnerability reports enable us to pinpoint areas needing improvement. We\'re actively working on adding support for select third-party libraries that have been a source of use-after-free bugs, as well as developing a more advanced rewriter tool that can handle transformations like converting std::vector into std::vector. We\'ve also made sever Tool Vulnerability Threat Mobile ★★★
GoogleSec.webp 2023-12-12 12:00:09 Durcissant les bandes de base cellulaire dans Android
Hardening cellular basebands in Android (lien direct)		 Posted by Ivan Lozano and Roger Piqueras Jover Android\'s defense-in-depth strategy applies not only to the Android OS running on the Application Processor (AP) but also the firmware that runs on devices. We particularly prioritize hardening the cellular baseband given its unique combination of running in an elevated privilege and parsing untrusted inputs that are remotely delivered into the device. This post covers how to use two high-value sanitizers which can prevent specific classes of vulnerabilities found within the baseband. They are architecture agnostic, suitable for bare-metal deployment, and should be enabled in existing C/C++ code bases to mitigate unknown vulnerabilities. Beyond security, addressing the issues uncovered by these sanitizers improves code health and overall stability, reducing resources spent addressing bugs in the future. An increasingly popular attack surface As we outlined previously, security research focused on the baseband has highlighted a consistent lack of exploit mitigations in firmware. Baseband Remote Code Execution (RCE) exploits have their own categorization in well-known third-party marketplaces with a relatively low payout. This suggests baseband bugs may potentially be abundant and/or not too complex to find and exploit, and their prominent inclusion in the marketplace demonstrates that they are useful. Baseband security and exploitation has been a recurring theme in security conferences for the last decade. Researchers have also made a dent in this area in well-known exploitation contests. Most recently, this area has become prominent enough that it is common to find practical baseband exploitation trainings in top security conferences. Acknowledging this trend, combined with the severity and apparent abundance of these vulnerabilities, last year we introduced updates to the severity guidelines of Android\'s Vulnerability Rewards Program (VRP). For example, we consider vulnerabilities allowing Remote Code Execution (RCE) in the cellular baseband to be of CRITICAL severity. Mitigating Vulnerability Root Causes with Sanitizers Common classes of vulnerabilities can be mitigated through the use of sanitizers provided by Clang-based toolchains. These sanitizers insert runtime checks against common classes of vulnerabilities. GCC-based toolchains may also provide some level of support for these flags as well, but will not be considered further in this post. We encourage you to check your toolchain\'s documentation. Two sanitizers included in Undefine Tool Vulnerability Threat Mobile Prediction Conference ★★★
GoogleSec.webp 2023-11-08 09:03:58 Évolution de l'App Defence Alliance
Evolving the App Defense Alliance (lien direct)		 Publié par Nataliya Stanetsky, Android Security and Privacy Team L'App Defence Alliance (ADA), une collaboration à la tête de l'industrie Lancé Par Google en 2019, dédié à garantir la sécurité de l'écosystème de l'application, fait un pas en avant majeur.Nous sommes fiers de Annonce que l'App Defence Alliance se déplace sous l'égide de la Fondation Linux, avec Meta, Microsoft et Google en tant que membres de la direction fondatrice. Cette migration stratégique représente un moment central dans le parcours de l'Alliance \\, ce qui signifie un engagement partagé par les membres pour renforcer la sécurité des applications et les normes connexes entre les écosystèmes.Cette évolution de l'App Defence Alliance nous permettra de favoriser une mise en œuvre plus collaborative des normes de l'industrie pour la sécurité des applications. Uniter pour la sécurité des applications Le paysage numérique évolue continuellement, tout comme les menaces pour la sécurité des utilisateurs.Avec la complexité toujours croissante des applications mobiles et l'importance croissante de la protection des données, c'est le moment idéal pour cette transition.La Fondation Linux est réputée pour son dévouement à favoriser des projets open source qui stimulent l'innovation, la sécurité et la durabilité.En combinant des forces avec des membres supplémentaires sous la Fondation Linux, nous pouvons nous adapter et répondre plus efficacement aux défis émergents. L'engagement de la nouvelle application de défense de la Defence Alliance \\ est des membres de la direction & # 8211;Meta, Microsoft et Google & # 8211;est essentiel pour faire de cette transition une réalité.Avec une communauté membre couvrant 16 membres généraux et contributeurs supplémentaires, l'alliance soutiendra l'adoption à l'échelle de l'industrie des meilleures pratiques et directives de la sécurité des applications, ainsi que des contre-mesures contre les risques de sécurité émergents. Poursuivant le programme d'atténuation des logiciels malveillants L'App Defence Alliance a été formée avec la mission de réduire le risque de logiciels malveillants basés sur l'application et de mieux protéger les utilisateurs d'Android.La défense malveillante reste un objectif important pour Google et Android, et nous continuerons de nous associer étroitement avec les membres du programme d'atténuation des logiciels malveillants & # 8211;ESET, Lookout, McAfee, Trend Micro, Zimperium & # 8211;sur le partage direct du signal.La migration de l'ADA sous la Fondation Linux permettra un partage plus large de l'intelligence des menaces à travers les principaux partenaires et chercheurs écosystémiques. en regardant vers l'avenir et en se connectant avec l'ADA Nous vous invitons à rester connecté avec la nouvelle Alliance de défense de l'application sous l'égide de la Fondation Linux.Rejoignez la conversation pour aider à rendre les applications plus sécurisées.Avec le comité directeur, Alliance Partners et l'écosystème plus large, nous sommes impatients de créer des écosystèmes d'applications plus sûrs et dignes de confiance.
Posted by Nataliya Stanetsky, Android Security and Privacy Team The App Defense Alliance (ADA), an industry-leading collaboration launched by Google in 2019 dedicated to ensuring the safety of the app ecosystem, is taking a major step forward. We are proud to 		Malware Threat Mobile Prediction ★★
GoogleSec.webp 2023-10-26 08:49:41 Increasing transparency in AI security (lien direct) Mihai Maruseac, Sarah Meiklejohn, Mark Lodato, Google Open Source Security Team (GOSST)New AI innovations and applications are reaching consumers and businesses on an almost-daily basis. Building AI securely is a paramount concern, and we believe that Google\'s Secure AI Framework (SAIF) can help chart a path for creating AI applications that users can trust. Today, we\'re highlighting two new ways to make information about AI supply chain security universally discoverable and verifiable, so that AI can be created and used responsibly. The first principle of SAIF is to ensure that the AI ecosystem has strong security foundations. In particular, the software supply chains for components specific to AI development, such as machine learning models, need to be secured against threats including model tampering, data poisoning, and the production of harmful content. Even as machine learning and artificial intelligence continue to evolve rapidly, some solutions are now within reach of ML creators. We\'re building on our prior work with the Open Source Security Foundation to show how ML model creators can and should protect against ML supply chain attacks by using Malware Tool Vulnerability Threat Cloud ★★
GoogleSec.webp 2023-09-27 12:51:29 Les lacunes de sécurité et de confidentialité SMS montrent clairement que les utilisateurs ont besoin d'une mise à niveau de messagerie
SMS Security & Privacy Gaps Make It Clear Users Need a Messaging Upgrade (lien direct)		 Posted by Eugene Liderman and Roger Piqueras Jover SMS texting is frozen in time. People still use and rely on trillions of SMS texts each year to exchange messages with friends, share family photos, and copy two-factor authentication codes to access sensitive data in their bank accounts. It\'s hard to believe that at a time where technologies like AI are transforming our world, a forty-year old mobile messaging standard is still so prevalent. Like any forty-year-old technology, SMS is antiquated compared to its modern counterparts. That\'s especially concerning when it comes to security. The World Has Changed, But SMS Hasn\'t Changed With It According to a recent whitepaper from Dekra, a safety certifications and testing lab, the security shortcomings of SMS can notably lead to: SMS Interception: Attackers can intercept SMS messages by exploiting vulnerabilities in mobile carrier networks. This can allow them to read the contents of SMS messages, including sensitive information such as two-factor authentication codes, passwords, and credit card numbers due to the lack of encryption offered by SMS. SMS Spoofing: Attackers can spoof SMS messages to launch phishing attacks to make it appear as if they are from a legitimate sender. This can be used to trick users into clicking on malicious links or revealing sensitive information. And because carrier networks have independently developed their approaches to deploying SMS texts over the years, the inability for carriers to exchange reputation signals to help identify fraudulent messages has made it tough to detect spoofed senders distributing potentially malicious messages. These findings add to the well-established facts about SMS\' weaknesses, lack of encryption chief among them. Dekra also compared SMS against a modern secure messaging protocol and found it lacked any built-in security functionality. According to Dekra, SMS users can\'t answer \'yes\' to any of the following basic security questions: Confidentiality: Can I trust that no one else can read my SMSs? Integrity: Can I trust that the content of the SMS that I receive is not modified? Authentication: Can I trust the identity of the sender of the SMS that I receive? But this isn\'t just theoretical: cybercriminals have also caught on to the lack of security protections SMS provides and have repeatedly exploited its weakness. Both novice hackers and advanced threat actor groups (such as UNC3944 / Scattered Spider and APT41 investigated by Mandiant, part of Google Cloud) leverage the security deficiencies in SMS to launch different Vulnerability Threat Studies APT 41 ★★★
GoogleSec.webp 2023-08-08 11:59:13 Android 14 présente les fonctionnalités de sécurité de la connectivité cellulaire en son genre
Android 14 introduces first-of-its-kind cellular connectivity security features (lien direct)		 Posted by Roger Piqueras Jover, Yomna Nasser, and Sudhi Herle Android is the first mobile operating system to introduce advanced cellular security mitigations for both consumers and enterprises. Android 14 introduces support for IT administrators to disable 2G support in their managed device fleet. Android 14 also introduces a feature that disables support for null-ciphered cellular connectivity. Hardening network security on Android The Android Security Model assumes that all networks are hostile to keep users safe from network packet injection, tampering, or eavesdropping on user traffic. Android does not rely on link-layer encryption to address this threat model. Instead, Android establishes that all network traffic should be end-to-end encrypted (E2EE). When a user connects to cellular networks for their communications (data, voice, or SMS), due to the distinctive nature of cellular telephony, the link layer presents unique security and privacy challenges. False Base Stations (FBS) and Stingrays exploit weaknesses in cellular telephony standards to cause harm to users. Additionally, a smartphone cannot reliably know the legitimacy of the cellular base station before attempting to connect to it. Attackers exploit this in a number of ways, ranging from traffic interception and malware sideloading, to sophisticated dragnet surveillance. Recognizing the far reaching implications of these attack vectors, especially for at-risk users, Android has prioritized hardening cellular telephony. We are tackling well-known insecurities such as the risk presented by 2G networks, the risk presented by null ciphers, other false base station (FBS) threats, and baseband hardening with our ecosystem partners. 2G and a history of inherent security risk The mobile ecosystem is rapidly adopting 5G, the latest wireless standard for mobile, and many carriers have started to turn down 2G service. In the United States, for example, most major carriers have shut down 2G networks. However, all existing mobile devices still have support for 2G. As a result, when available, any mobile device will connect to a 2G network. This occurs automatically when 2G is the only network available, but this can also be remotely triggered in a malicious attack, silently inducing devices to downgrade to 2G-only connectivity and thus, ignoring any non-2G network. This behavior happens regardless of whether local operators have already sunset their 2G infrastructure. 2G networks, first implemented in 1991, do not provide the same level of security as subsequent mobile generat Malware Tool Threat Conference ★★★
GoogleSec.webp 2023-07-27 12:01:55 Les hauts et les bas de 0 jours: une année en revue des 0 jours exploités dans le monde en 2022
The Ups and Downs of 0-days: A Year in Review of 0-days Exploited In-the-Wild in 2022 (lien direct)		 Maddie Stone, Security Researcher, Threat Analysis Group (TAG)This is Google\'s fourth annual year-in-review of 0-days exploited in-the-wild [2021, 2020, 2019] and builds off of the mid-year 2022 review. The goal of this report is not to detail each individual exploit, but instead to analyze the exploits from the year as a whole, looking for trends, gaps, lessons learned, and successes. Executive Summary41 in-the-wild 0-days were detected and disclosed in 2022, the second-most ever recorded since we began tracking in mid-2014, but down from the 69 detected in 2021.  Although a 40% drop might seem like a clear-cut win for improving security, the reality is more complicated. Some of our key takeaways from 2022 include:N-days function like 0-days on Android due to long patching times. Across the Android ecosystem there were multiple cases where patches were not available to users for a significant time. Attackers didn\'t need 0-day exploits and instead were able to use n-days that functioned as 0-days. Tool Vulnerability Threat Prediction Conference ★★★
GoogleSec.webp 2023-07-20 12:00:23 Un regard sur la culture de la révision de la sécurité de Chrome \\
A look at Chrome\\'s security review culture (lien direct)		 Posted by Alex Gough, Chrome Security Team Security reviewers must develop the confidence and skills to make fast, difficult decisions. A simplistic piece of advice to reviewers is “just be confident” but in reality that takes practice and experience. Confidence comes with time, and people are there to support each other as we learn. This post shares advice we give to people doing security reviews for Chrome. Security Review in Chrome Chrome has a lightweight launch process. Teams write requirements and design documents outlining why the feature should be built, how the feature will benefit users, and how the feature will be built. Developers write code behind a feature flag and must pass a Launch Review before turning it on. Teams think about security early-on and coordinate with the security team. Teams are responsible for the safety of their features and ensuring that the security team is able to say \'yes\' to its security review. Security review focuses on the design of a proposed feature, not its details and is distinct from code review. Chrome changes need approval from engineers familiar with the code being changed but not necessarily from security experts. It is not practical for security engineers to scrutinize every change. Instead we focus on the feature\'s architecture, and how it might affect people using Chrome. Reviewers function best in an open and supportive engineering culture. Security review is not an easy task – it applies security engineering insights in a social context that could become adversarial and fractious. Google, and Chrome, embody a security-centric engineering culture, where respectful disagreement is valued, where we learn from mistakes, where decisions can be revisited, and where developers see the security team as a partner that helps them ship features safely. Within the security team we support each other by encouraging questioning & learning, and provide mentorship and coaching to help reviewers enhance their reviewing skills. Learning security review Start by shadowing Start with some help. As a new reviewer, you may not feel you\'re 100% ready - don\'t let that put you off. The best way to learn is to observe and see what\'s involved before easing in to doing reviews on your own. Start by shadowing to get a feel for the process. Ask the person you are shadowing how they plan to approach the review, then look at the materials yourself. Concentrate on learning how to review rather than on the details of the thing you are reviewing. Don\'t get too involved but observe how the reviewer does things and ask them why. Next time try to co-review something - ask the feature team some questions and talk through your thoughts with the other reviewer. Let them make the final approval decision. Do this a few times and you\'ll be ready to be the main reviewer, and remember that you can always reach out for help and advice. Read enough to make a decision Read a lot, but know when to stop. Understand what the feature is doing, what\'s new, and what\'s built on existing, approved, mechanisms. Focus on the new things. If you need to educate yourself, skim older docs or code for context. It can help to look at related reviews for repeated issues and solutions. It is tempting to try to understand everything and at first you\'ll dig deeper than you need to. You\'ll get better at knowing when to stop after a few reviews. Treat existing, approved, features as building blocks that you don\'t need to fully understand, but might be useful to skim as background. Threat ★★
GoogleSec.webp 2023-06-01 11:59:52 Annonce du bonus d'exploitation en pleine chaîne du navigateur Chrome
Announcing the Chrome Browser Full Chain Exploit Bonus (lien direct)		 Amy Ressler, Chrome Security Team au nom du Chrome VRP Depuis 13 ans, un pilier clé de l'écosystème de sécurité chromée a inclus des chercheurs en sécurité à trouver des vulnérabilités de sécurité dans Chrome Browser et à nous les signaler, à travers le Programme de récompenses de vulnérabilité Chrome . À partir d'aujourd'hui et jusqu'au 1er décembre 2023, le premier rapport de bogue de sécurité que nous recevons avec un exploit fonctionnel de la chaîne complète, résultant en une évasion chromée de sable, est éligible à triple le montant de la récompense complet .Votre exploit en pleine chaîne pourrait entraîner une récompense pouvant atteindre 180 000 $ (potentiellement plus avec d'autres bonus). Toutes les chaînes complètes ultérieures soumises pendant cette période sont éligibles pour doubler le montant de récompense complet ! Nous avons historiquement mis une prime sur les rapports avec les exploits & # 8211;«Des rapports de haute qualité avec un exploit fonctionnel» est le niveau le plus élevé de montants de récompense dans notre programme de récompenses de vulnérabilité.Au fil des ans, le modèle de menace de Chrome Browser a évolué à mesure que les fonctionnalités ont mûri et de nouvelles fonctionnalités et de nouvelles atténuations, tels a miracleptr , ont été introduits.Compte tenu de ces évolutions, nous sommes toujours intéressés par les explorations d'approches nouvelles et nouvelles pour exploiter pleinement le navigateur Chrome et nous voulons offrir des opportunités pour mieux inciter ce type de recherche.Ces exploits nous fournissent un aperçu précieux des vecteurs d'attaque potentiels pour exploiter Chrome et nous permettent d'identifier des stratégies pour un meilleur durcissement des caractéristiques et des idées de chrome spécifiques pour de futures stratégies d'atténuation à grande échelle. Les détails complets de cette opportunité de bonus sont disponibles sur le Chrome VRP Rules and Rewards page .Le résumé est le suivant: Les rapports de bogues peuvent être soumis à l'avance pendant que le développement de l'exploitation se poursuit au cours de cette fenêtre de 180 jours.Les exploits fonctionnels doivent être soumis à Chrome à la fin de la fenêtre de 180 jours pour être éligible à la triple ou double récompense. Le premier exploit fonctionnel de la chaîne complète que nous recevons est éligible au triple de récompense. L'exploit en chaîne complète doit entraîner une évasion de bac à sable de navigateur Chrome, avec une démonstration de contrôle / exécution de code de l'attaquant en dehors du bac à sable. L'exploitation doit pouvoir être effectuée à distance et aucune dépendance ou très limitée à l'interaction utilisateur. L'exploit doit avoir été fonctionnel dans un canal de libération actif de Chrome (Dev, Beta, stable, étendu stable) au moment des rapports initiaux des bogues dans cette chaîne.Veuillez ne pas soumettre des exploits développés à partir de bogues de sécurité divulgués publiquement ou d'autres artefacts dans les anciennes versions passées de Chrome. Comme cela est conforme à notre politique générale de récompenses, si l'exploit permet l'exécution du code distant (RCE) dans le navigateur ou un autre processus hautement privilégié, tel que le processus de réseau ou de GPU, pour entraîner une évasion de bac à sable sans avoir besoin d'une première étapeBug, le montant de récompense pour le rendu «rapport de haute qualité avec exploit fonctionnel» serait accordé et inclus dans le calcul du total de récompense de bonus. Sur la base de notre Vulnerability Threat ★★★
GoogleSec.webp 2023-05-24 12:49:28 Annonçant le lancement de Guac V0.1
Announcing the launch of GUAC v0.1 (lien direct)		 Brandon Lum and Mihai Maruseac, Google Open Source Security TeamToday, 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 GUACHigh-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 Tool Vulnerability Threat Yahoo ★★
GoogleSec.webp 2023-04-18 12:00:25 Hébergeant en toute sécurité les données des utilisateurs dans les applications Web modernes
Securely Hosting User Data in Modern Web Applications (lien direct)		 Posted by David Dworken, Information Security Engineer, Google Security Team Many web applications need to display user-controlled content. This can be as simple as serving user-uploaded images (e.g. profile photos), or as complex as rendering user-controlled HTML (e.g. a web development tutorial). This has always been difficult to do securely, so we\'ve worked to find easy, but secure solutions that can be applied to most types of web applications. Classical Solutions for Isolating Untrusted Content The classic solution for securely serving user-controlled content is to use what are known as “sandbox domains”. The basic idea is that if your application\'s main domain is example.com, you could serve all untrusted content on exampleusercontent.com. Since these two domains are cross-site, any malicious content on exampleusercontent.com can\'t impact example.com. This approach can be used to safely serve all kinds of untrusted content including images, downloads, and HTML. While it may not seem like it is necessary to use this for images or downloads, doing so helps avoid risks from content sniffing, especially in legacy browsers. Sandbox domains are widely used across the industry and have worked well for a long time. But, they have two major downsides: Applications often need to restrict content access to a single user, which requires implementing authentication and authorization. Since sandbox domains purposefully do not share cookies with the main application domain, this is very difficult to do securely. To support authentication, sites either have to rely on capability URLs, or they have to set separate authentication cookies for the sandbox domain. This second method is especially problematic in the modern web where many browsers restrict cross-site cookies by default. While user content is isolated from the main site, it isn\'t isolated from other user content. This creates the risk of malicious user content attacking other data on the sandbox domain (e.g. via reading same-origin data). It is also worth noting that sandbox domains help mitigate phishing risks since resources are clearly segmented onto an isolated domain. Modern Solutions for Serving User Content Over time the web has evolved, and there are now easier, more secure ways to serve untrusted content. There are many different approaches here, so we will outline two solutions that are currently in wide use at Google. Approach 1: Serving Inactive User Content If a site only needs to serve inactive user content (i.e. content that is not HTML/JS, for example images and downloads), this can now be safely done without an isolated sandbox domain. There are two key steps: Always set the Content-Type header to a well-known MIME type that is supported by all browsers and guaranteed not to contain active content (when in doubt, application/octet-stream is a safe choice). In addition, always set the below response headers to ensure that the browser fully isolates the response. Threat ★★
GoogleSec.webp 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 ★★★
GoogleSec.webp 2023-02-13 12:01:11 The US Government says companies should take more responsibility for cyberattacks. We agree. (lien direct) Posted by Kent Walker, President, Global Affairs & Chief Legal Officer, Google & Alphabet and Royal Hansen, Vice President of Engineering for Privacy, Safety, and Security Should companies be responsible for cyberattacks? The U.S. government thinks so – and frankly, we agree. Jen Easterly and Eric Goldstein of the Cybersecurity and Infrastructure Security Agency at the Department of Homeland Security planted a flag in the sand: “The incentives for developing and selling technology have eclipsed customer safety in importance. […] Americans…have unwittingly come to accept that it is normal for new software and devices to be indefensible by design. They accept products that are released to market with dozens, hundreds, or even thousands of defects. They accept that the cybersecurity burden falls disproportionately on consumers and small organizations, which are often least aware of the threat and least capable of protecting themselves.”We think they're right. It's time for companies to step up on their own and work with governments to help fix a flawed ecosystem. Just look at the growing threat of ransomware, where bad actors lock up organizations' systems and demand payment or ransom to restore access. Ransomware affects every industry, in every corner of the globe – and it thrives on pre-existing vulnerabilities: insecure software, indefensible architectures, and inadequate security investment. Remember that sophisticated ransomware operators have bosses and budgets too. They increase their return on investment by exploiting outdated and insecure technology systems that are too hard to defend. Alarmingly, the most significant source of compromise is through exploitation of known vulnerabilities, holes sometimes left unpatched for years. While law enforcement works to bring ransomware operators to justice, this merely treats the symptoms of the problem. Treating the root causes will require addressing the underlying sources of digital vulnerabilities. As Easterly and Goldstein rightly point out, “secure by default” and “secure by design” should be table stakes. The bottom line: People deserve products that are secure by default and systems that are built to withstand the growing onslaught from attackers. Safety should be fundamental: built-in, enabled out of the box, and not added on as an afterthought. In other words, we need secure products, not security products. That's why Google has worked to build security in – often making it invisible – to our users. Many of our most significant security features, including innovations like SafeBrowsing, do their best work behind the scenes for our core consumer products. There's come to be an unfortunate belief that security features are cumbersome and hurt user experience. That can be true – but it doesn't need to be. We can make the safe path the easiest, most helpful path for people using our products. Our approach to multi-factor authentication – one of the most important controls to defend against phishing attacks – provides a great example. Since 2021, we've turned on 2-Step Verification (2SV) by default for hundreds of millions of people to add an additional layer of security across their online accounts. If we had simply announced 2SV as an available option for people to enroll in, it would have failed like so many other security add-ons. Instead, we pioneered an approach using in-app notifications that was so seamless and integrated, many of the millions of people we auto-enrolled never noticed they adopted 2SV. We've taken this approach even further by build Ransomware Threat ★★★
GoogleSec.webp 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
GoogleSec.webp 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
GoogleSec.webp 2022-08-24 13:14:56 Announcing the Open Sourcing of Paranoid\'s Library (lien direct) Posted by Pedro Barbosa, Security Engineer, and Daniel Bleichenbacher, Software EngineerParanoid is a project to detect well-known weaknesses in large amounts of crypto artifacts, like public keys and digital signatures. On August 3rd 2022 we open sourced the library containing the checks that we implemented so far (https://github.com/google/paranoid_crypto). The library is developed and maintained by members of the Google Security Team, but it is not an officially supported Google product.Why the Project?Crypto artifacts may be generated by systems with implementations unknown to us; we refer to them as “black boxes.” An artifact may be generated by a black-box if, for example, it was not generated by one of our own tools (such as Tink), or by a library that we can inspect and test using Wycheproof. Unfortunately, sometimes we end up relying on black-box generated artifacts (e.g. generated by proprietary HSMs).After the disclosure of the ROCA vulnerability Vulnerability Threat
GoogleSec.webp 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
GoogleSec.webp 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
GoogleSec.webp 2022-05-18 09:03:33 Privileged pod escalations in Kubernetes and GKE (lien direct) Posted by GKE and Anthos Platform Security Teams At the KubeCon EU 2022 conference in Valencia, security researchers from Palo Alto Networks presented research findings on “trampoline pods”-pods with an elevated set of privileges required to do their job, but that could conceivably be used as a jumping off point to gain escalated privileges.The research mentions GKE, including how developers should look at the privileged pod problem today, what the GKE team is doing to minimize the use of privileged pods, and actions GKE users can take to protect their clusters.Privileged pods within the context of GKE securityWhile privileged pods can pose a security issue, it's important to look at them within the overall context of GKE security. To use a privileged pod as a “trampoline” in GKE, there is a major prerequisite – the attacker has to first execute a successful application compromise and container breakout attack. Because the use of privileged pods in an attack requires a first step such as a container breakout to be effective, let's look at two areas:features of GKE you can use to reduce the likelihood of a container breakoutsteps the GKE team is taking to minimize the use of privileged pods and the privileges needed in them.Reducing container breakoutsThere are a number of features in GKE along with some best practices that you can use to reduce the likelihood of a container breakout:Use GKE Sandbox to strengthen the container security boundary. Over the last few months, GKE Sandbox has protected containers running it against several newly discovered Linux kernel breakout CVEs.Adopt GKE Autopilot for new clusters. Autopilot clusters have default policies that prevent host access through mechanisms like host path volumes and host network. The container runtime default seccomp profile is also enabled by default on Autopilot which has prevented several breakouts.Subscribe to GKE Release Channels and use autoupgrade to keep nodes patched automatically against kernel vulnerabilities.Run Google's Container Optimized OS, the minimal and hardened container optimized OS that makes much of the disk read-only.Incorporate binary authorization into your SDLC to require that containers admitted into the cluster are from trusted build systems and up-to-date on patching.Use Secure Command Center's Container Threat Detection or supported third-party tools to detect the most common runtime attacks.More information can be found in the GKE Hardening Guide.How GKE is reducing the use of privileged pod Tool Threat Uber
GoogleSec.webp 2022-05-11 15:36:41 Taking on the Next Generation of Phishing Scams (lien direct) Posted by Daniel Margolis, Software Engineer, Google Account Security Team Every year, security technologies improve: browsers get better, encryption becomes ubiquitous on the Web, authentication becomes stronger. But phishing persistently remains a threat (as shown by a recent phishing attack on the U.S. Department of Labor) because users retain the ability to log into their online accounts, often with a simple password, from anywhere in the world. It's why today at I/O we announced new ways we're reducing the risks of phishing by: scaling phishing protections to Google Docs, Sheets and Slides, continuing to auto enroll people in 2-Step Verification and more. This blog will deep dive into the method of phishing and how it has evolved today. As phishing adoption has grown, multi-factor authentication has become a particular focus for attackers. In some cases, attackers phish SMS codes directly, by following a legitimate "one-time passcode" (triggered by the attacker trying to log into the victim's account) with a spoofed message asking the victim to "reply back with the code you just received.” Left: legitimate Google SMS verification. Right: spoofed message asking victim to share verification code.In other cases, attackers have leveraged more sophisticated dynamic phishing pages to conduct relay attacks. In these attacks, a user thinks they're logging into the intended site, just as in a standard phishing attack. But instead of deploying a simple static phishing page that saves the victim's email and password when the victim tries to login, the phisher has deployed a web service that logs into the actual website at the same time the user is falling for the phishing page.The simplest approach is an almost off-the-shelf "reverse proxy" which acts as a "person in the middle", forwarding the victim's inputs to the legitimate page and sending the response from the legitimate page back to the victim's browser. Threat
Last update at: 2024-05-16 16:08:16
See our sources.
My email:

To see everything: Our RSS (filtrered) Twitter