As more and more hotels are turning rooms into offices, the FBI is warning remote workers of cyber-threats lurking in the shadows
The post Working from a hotel? Beware the dangers of public Wi‑Fi appeared first on WeLiveSecurity
Companies facilitating ransomware payments run the risk of facing stern penalties for violating US regulations
The post US gov’t warns against paying off ransomware attackers appeared first on WeLiveSecurity
Passwords are often the first line of defense for our digital lives. Today, we’re improving password security on both Android and iOS devices by telling you if the passwords you’ve asked Chrome to remember have been compromised, and if so, how to fix them.
To check whether you have any compromised passwords, Chrome sends a copy of your usernames and passwords to Google using a special form of encryption. This lets Google check them against lists of credentials known to be compromised, but Google cannot derive your username or password from this encrypted copy.
We notify you when you have compromised passwords on websites, but it can be time-consuming to go find the relevant form to change your password. To help, we’re adding support for “.well-known/change-password” URLs that let Chrome take users directly to the right “change password” form after they’ve been alerted that their password has been compromised.
Along with these improvements, Chrome is also bringing Safety Check to mobile. In our next release, we will launch Safety Check on iOS and Android, which includes checking for compromised passwords, telling you if Safe Browsing is enabled, and whether the version of Chrome you are running is updated with the latest security protections. You will also be able to use Chrome on iOS to autofill saved login details into other apps or browsers.
In Chrome 86 we’ll also be launching a number of additional features to improve user security, including:
Enhanced Safe Browsing for Android
Earlier this year, we launched Enhanced Safe Browsing for desktop, which gives Chrome users the option of more advanced security protections.
When you turn on Enhanced Safe Browsing, Chrome can proactively protect you against phishing, malware, and other dangerous sites by sharing real-time data with Google’s Safe Browsing service. Among our users who have enabled checking websites and downloads in real time, our predictive phishing protections see a roughly 20% drop in users typing their passwords into phishing sites.
Improvements to password filling on iOS
We recently launched Touch-to-fill for passwords on Android to prevent phishing attacks. To improve security on iOS too, we’re introducing a biometric authentication step before autofilling passwords. On iOS, you’ll now be able to authenticate using Face ID, Touch ID, or your phone passcode. Additionally, Chrome Password Manager allows you to autofill saved passwords into iOS apps or browsers if you enable Chrome autofill in Settings.
Mixed form warnings and download blocking
Update (10/07/2020): Mixed form warnings were originally scheduled for Chrome 86, but will be delayed until Chrome 87
Secure HTTPS pages may sometimes still have non-secure features. Earlier this year, Chrome began securing and blocking what’s known as “mixed content”, when secure pages incorporate insecure content. But there are still other ways that HTTPS pages can create security risks for users, such as offering downloads over non-secure links, or using forms that don’t submit data securely.
To better protect users from these threats, Chrome 86 is introducing mixed form warnings on desktop and Android to alert and warn users before submitting a non-secure form that’s embedded in an HTTPS page.
Additionally, Chrome 86 will block or warn on some insecure downloads initiated by secure pages. Currently, this change affects commonly abused file types, but eventually secure pages will only be able to initiate secure downloads of any type. For more details, see Chrome’s plan to gradually block mixed downloads altogether
We encourage developers to update their forms and downloads to use secure connections for the safety and privacy of their users.
It’s easy to reset your password or PIN after a data breach. But reset your face? Not so much.
The post Had your face stolen lately? appeared first on WeLiveSecurity
As we steadily adopt smart devices into our lives, we shouldn’t forget about keeping them secured and our data protected
The post 5 steps to secure your connected devices appeared first on WeLiveSecurity
Posted by Kylie McRoberts, Program Manager and Alec Guertin, Security Engineer
Google’s Android Security & Privacy team has launched the Android Partner Vulnerability Initiative (APVI) to manage security issues specific to Android OEMs. The APVI is designed to drive remediation and provide transparency to users about issues we have discovered at Google that affect device models shipped by Android partners.
Another layer of security
Android incorporates industry-leading security features and every day we work with developers and device implementers to keep the Android platform and ecosystem safe. As part of that effort, we have a range of existing programs to enable security researchers to report security issues they have found. For example, you can report vulnerabilities in Android code via the Android Security Rewards Program (ASR), and vulnerabilities in popular third-party Android apps through the Google Play Security Rewards Program. Google releases ASR reports in Android Open Source Project (AOSP) based code through the Android Security Bulletins (ASB). These reports are issues that could impact all Android based devices. All Android partners must adopt ASB changes in order to declare the current month’s Android security patch level (SPL). But until recently, we didn’t have a clear way to process Google-discovered security issues outside of AOSP code that are unique to a much smaller set of specific Android OEMs. The APVI aims to close this gap, adding another layer of security for this targeted set of Android OEMs.
Improving Android OEM device security
The APVI covers Google-discovered issues that could potentially affect the security posture of an Android device or its user and is aligned to ISO/IEC 29147:2018 Information technology — Security techniques — Vulnerability disclosure recommendations. The initiative covers a wide range of issues impacting device code that is not serviced or maintained by Google (these are handled by the Android Security Bulletins).
Protecting Android users
The APVI has already processed a number of security issues, improving user protection against permissions bypasses, execution of code in the kernel, credential leaks and generation of unencrypted backups. Below are a few examples of what we’ve found, the impact and OEM remediation efforts.
Permission Bypass
In some versions of a third-party pre-installed over-the-air (OTA) update solution, a custom system service in the Android framework exposed privileged APIs directly to the OTA app. The service ran as the system user and did not require any permissions to access, instead checking for knowledge of a hardcoded password. The operations available varied across versions, but always allowed access to sensitive APIs, such as silently installing/uninstalling APKs, enabling/disabling apps and granting app permissions. This service appeared in the code base for many device builds across many OEMs, however it wasn’t always registered or exposed to apps. We’ve worked with impacted OEMs to make them aware of this security issue and provided guidance on how to remove or disable the affected code.
Credential Leak
A popular web browser pre-installed on many devices included a built-in password manager for sites visited by the user. The interface for this feature was exposed to WebView through JavaScript loaded in the context of each web page. A malicious site could have accessed the full contents of the user’s credential store. The credentials are encrypted at rest, but used a weak algorithm (DES) and a known, hardcoded key. This issue was reported to the developer and updates for the app were issued to users.
Overly-Privileged Apps
The checkUidPermission method in the PackageManagerService class was modified in the framework code for some devices to allow special permissions access to some apps. In one version, the method granted apps with the shared user ID com.google.uid.shared any permission they requested and apps signed with the same key as the com.google.android.gsf package any permission in their manifest. Another version of the modification allowed apps matching a list of package names and signatures to pass runtime permission checks even if the permission was not in their manifest. These issues have been fixed by the OEMs.
More information
Keep an eye out at https://bugs.chromium.org/p/apvi/ for future disclosures of Google-discovered security issues under this program, or find more information there on issues that have already been disclosed.
Acknowledgements: Scott Roberts, Shailesh Saini and Łukasz Siewierski, Android Security and Privacy Team
ESET research unearths a previously unknown espionage gang and a new version of Android spyware – Elucidating connections between Latin American banking trojans
The post Week in security with Tony Anscombe appeared first on WeLiveSecurity
ESET researchers uncover a new APT group that has been stealing sensitive documents from several governments in Eastern Europe and the Balkans since 2011
The post XDSpy: Stealing government secrets since 2011 appeared first on WeLiveSecurity
A month teaching us that when everyone pitches in and does their part, then almost everyone is protected
The post Cyber Security Awareness Month is here! appeared first on WeLiveSecurity
ESET researchers discover surprisingly many indicators of close cooperation among Latin American banking trojans’ authors
The post LATAM financial cybercrime: Competitors‑in‑crime sharing TTPs appeared first on WeLiveSecurity
Easy Contact
253 Main Ave, Passaic NJ 07055Call 973-777-5656
info@advantagecomputers.com
Fax 973-777-5821
© 2024 ~ All Rights Reserved
Advantage Computer Solutions