Avatier simplifies and secures IAM with release of iOS and Android mobile app platform

Avatier announced the release of Avatier for iOS and Android, a new mobile app platform that creates a collaborative, self-service approach to enterprise access without compromising security.

Avatier promises to simplify identity access management (IAM) by empowering organizations with greater control over enterprise access requests, compliance access certifications, single sign-on (SSO) to reduce SaaS license cost and self-service password management, all for a better value than buying individual point solutions.

Avatier’s new mobile experience is designed for the modern workforce, giving employees, customers, contractors and vendors a single mobile app that enables self-service business agility for time-sensitive security requests.

Now anyone in the company can be alerted on their mobile device to approve business requests to access data and assets. Change management for the entire business can run through Avatier’s new mobile workflow experience, reducing overhead for IGA, streamlining provisioning and ensuring security compliance.

The new mobile platform is secure and frictionless because Avatier’s password-less authentication automatically integrates with third-party multifactor authentication (MFA) solutions already deployed in most enterprises.

Avatier has MFA support for Duo Security, Google Authenticator, Okta Verify, Ping Identity, Radius, RSA SecureID, Symantec VIP and any FIDO2-compliant solution. Additionally, Avatier provides one-time passcode (OTP) support for SMS and email as well as biometric MFA solutions.

“IT staffs spend an inordinate amount of time managing user access requests and conducting access audits,” said Nelson Cicchitto, founder and CEO of Avatier.

“Research from HDI shows that 30 percent of help desk calls are for access requests at an average cost of 17 dollars per call. Avatier’s user experience changes the game with push notifications and a touch interface that can save companies millions of dollars by streamlining security controls and authorization while enabling their entire workforce to approve access immediately when needed.

“With Avatier’s mobile application support, CSOs, IT personnel, security and compliance teams save time and resources by simplifying identity management and truly enabling enterprise-wide self-service.”

Avatier’s mobile platform includes a complete set of self-service identity management solutions, including:

  • Universal workflow: For the first time, the workflow interface used for all business requests and change control is now also the same interface used to conduct certification campaigns and verify access. Push notifications call attention to urgent business requests that need to be approved or denied. All role, access, assets, change control and user management is controlled through Avatier’s Universal Workflow Platform. Access governance is part of workflow support, streamlining verification of granular access/assets, roles, direct reports, self-certification and native system security controls., including empowering attestors to allow, deny, allow exceptions, reassign attestor, or even return to the certification campaign owner.
  • Self-service group management: Enable self-service group membership requests with push notification for workflow approvals, including group creation, deletion, renaming and modifying group ownership.
  • User management: User access can be granted, disabled, or deleted either in real-time or as a scheduled task. As part of user management, Avatier Mobile makes it easy to manage data assets and software licenses to reallocate seats as needed.
  • Single sign-on: Onboard mobile and remote workers faster with Just-in-Time (JIT) cloud app user provisioning and de-provisioning to provide secure remote access to assets by simply adding users to your active directory groups. Avatier SSO supports leading industry standards like SAML, oAuth, OpenID and SCIM for JIT provisioning.
  • Self-service password management: Eliminate help desk calls by giving users secure control over password reset and synchronization using leading MFA providers to verify identity. Avatier’s Password Policy Manager enforces enterprise password policy to maintain strong passwords across all systems.

New Privacy Features in iOS 14

About Bruce Schneier

I am a public-interest technologist, working at the intersection of security, technology, and people. I’ve been writing about security issues on my blog since 2004, and in my monthly newsletter since 1998. I’m a fellow and lecturer at Harvard’s Kennedy School and a board member of EFF. This personal website expresses the opinions of neither of those organizations.

Chrome 86 delivers more security features for mobile users

Google has released Chrome 86 for desktop and mobile, which comes with several new and improved security features for mobile users, including:

  • New password protections
  • Enhanced Safe Browsing
  • Easier password filling
  • Mixed form warnings and mixed downloads warnings/blocks

New password security features in Chrome 86

The Password Checkup feature came first in the form of a Chrome extension, then was built into Google Account’s password manager and Chrome, and now it has been enhanced with support for the “.well-known/change-password” standard – a W3C specification that defines a well-known URL that sites can use to make their change password forms discoverable by tools (e.g. Chrome, or the latest version of Safari)

Chrome 86 security

This change means that, after they’ve been alerted that their password has been compromised, Chrome will take users directly to the right “change password” form. Hopefully, this will spur more users to act upon the alert.

Enhanced Safe Browsing is added to Chrome for Android

Enhanced Safe Browsing mode, which was first introduced in Chrome 83 (for desktop versions), allows users to get a more personalized protection against malicious sites.

“When you turn on Enhanced Safe Browsing, Chrome can proactively protect you against phishing, malware, and other dangerous sites by sharing real-time data with Google’s Safe Browsing service. Among our users who have enabled checking websites and downloads in real time, our predictive phishing protections see a roughly 20% drop in users typing their passwords into phishing sites,” noted AbdelKarim Mardini, Senior Product Manager, Chrome.

In addition to this, Safety Check – an option that allows users to scan their Chrome installation to check whether the browser is up to date, whether the Safe Browsing service is enabled, and whether any of the passwords the user uses have been compromised in a known breach – is now available to Chrome for Android and iOS.

Biometric authentication for autofilling of passwords on iOS

iOS users can finally take advantage of the convenient password autofill option that was made available a few months ago to Android users.

The option allows iOS users to authenticate using Face ID, Touch ID, or their phone passcode before their saved passwords are automatically filled into sites and iOS apps (the Chrome autofill option must be turned on in Settings).

Chrome 86 security

Mixed form/download warnings

Mixed content, i.e., insecure content served from otherwise secure (HTTPS) pages, is a danger to users.

Chrome 86 will warn users when they are about to submit information through a non-secure form embedded in an HTTPS page and when they are about to initiate insecure downloads over non-secure links.

For the moment, Chrome will block the download of executables and archive files over non-secure links but show a warning if the user tries to download documents files, PDFs, and multimatedia files. The next few Chrome versions will block those as well.

Last but not least, Google has fixed 35 security issues in Chrome 86, including a critical use after free vulnerabilities in payments (CVE-2020-15967).

iOS 14: New privacy and security features

Apple has released iOS 14, with a bucketload of new and improved functional features and a handful of privacy and security ones.

iOS 14 privacy security

New privacy and security features in iOS 14

The new iOS will tell you when an app is using your camera or microphone

It will show an indicator dot (green for when camera or camera+microphone is in use, orange for microphone) in the top right part of the device’s screen.

iOS 14 privacy security

The downside is that it’s fairly small and you might miss it if other things are happening on the screen. The upside is that you can check which app most recently used your camera or microphone via the Control Center.

Of course, you can deny access to your camera and microphone to any app through the Privacy settings.

You can share with apps your approximate location instead of the precise one

Go to Settings > Privacy and Location Services > Location Services, and you can configure for each app whether you want it to access your device’s location “only while the app is in use”, “always”, “never”, or you want the app to ask you for permission each time you run it (then you get the option to give it permission to access your location “Only once”).

When you allow location access for an app, you’ll get the option to provide your precise location or leave it to the app to determine your approximate location (the latter is good enough for apps that show local news or weather).

You can choose to share with apps just some photos

Under Privacy > Photos you can see which apps have requested access to your photos and you can choose to restrict each app’s access just to selected photos or photo albums (or none).

You can limit tracking

Each time you connect to a Wi-Fi network your phone will show a different MAC address. This is to prevent ISPs and advertisers to track your movements (i.e., see when and where you connect to a network), and this option is on by default.

In Settings > Privacy > Tracking, you can choose to not allow apps to send you a request to track you. If you do that, “any app that attempts to ask you for your permission will be blocked from asking and automatically informed that you have requested not to be tracked. In addition, all apps, other than those that you have previously given permission to track, will be blocked from accessing the device’s Advertising Identifier.”

If you allow tracking, tracking permissions can also be controlled on a per-app basis.

It has to be pointed out, though, that these app tracking options will start working as intended in early 2021, when these privacy controls become mandatory for developers.

“We want to give developers the time they need to make the necessary changes, and as a result, the requirement to use this tracking permission will go into effect early next year,” Apple explained.

Facebook complained earlier this year that these new privacy requirements would have a significant negative impact on its advertising business.

You will be able to see a summary of an app’s privacy practices before you download it from the App Store

You still can’t see these because app developers have yet to roll them out, but when they are ready, you’ll be able to peruse these summaries through a “App Privacy” button on the listing in the store, and they will look something like this:

iOS 14 privacy security

You’ll be able to see which tracking cookies have been blocked

The Safari mobile browser has been updated to show a Privacy Report, which shows all the cross-site tracking cookies it has blocked in the last 30 days if you turned on Prevent Cross-Site Tracking in Safari’s Privacy and Security Settings.

The report is accessible from the AA menu in the browser’s address bar.

You’ll be notified if a password you stored in the iCloud Keychain has been spotted in a known data breach

To turn this option on, go to Settings > Passwords > Security Recommendations and toggle on Detect Compromised Passwords. For the secure password monitoring to work, iCloud Keychain has to be enabled.

Fixed vulnerabilities

In iOS 14, Apple has also fixed a number of security vulnerabilities, including:

  • A vulnerability in an integrated drive electronics (IDE) component that could allow a remote authenticated attacker to execute arbitrary code on a paired device during a debug session over the network (CVE-2020-9992), and a
  • A logic issue affecting the sandbox that may allow a malicious application to access restricted files (CVE-2020-9968)

Malicious iOS SDK breaches user privacy for millions

Researchers discovered a malicious functionality within the iOS MintegralAdSDK (aka SourMint), distributed by Chinese company Mintegral.

malicious iOS SDK

Functional flow of a user ad-click being hijacked by the Mintegral SDK

Major privacy concerns

According to Snyk, SourMint actively performed ad fraud on hundreds of iOS apps and brought with it major privacy concerns to hundreds of millions of consumers.

On the surface, the MintegralAdSDK posed as a legitimate advertising SDK for iOS app developers, but its malicious code appeared to commit ad attribution fraud by secretly accessing link clicking activity within thousands of iOS apps that use the SDK.

SourMint also spied on user link click activity, improperly tracking requests performed by the app and reporting it back to Mintegral’s servers. Snyk’s researchers exposed SourMint and responsibly disclosed the information to Apple, alerting them to the active supply chain attack.

The SDK was distributed through Mintegral’s GitHub Repository, Cocoapods Package Manager for iOS; and Gradle/Maven for Android (which does not appear to be malicious). Unbeknownst to developers integrating it into their applications, the iOS versions of the SDK were malicious.

The SDK remained undetected for more than a year within the Apple App Store; SourMint first appeared in the 5.51 version of iOS in July 2019 continuing through version 6.3.7.0. Since then it has been identified in 1,200 iOS apps, including approximately 70 of the top 500 free apps found on the App Store, some of which are in the top 100.

Malicious iOS SDK functionality

Researchers found that SourMint has two major malicious functionalities in the SDK:

  • Compromising app user privacy SourMint monitored and tracked when users clicked on links, spying on individual link activity by hooking onto the communication functions the iOS app user deployed. The SDK inserted itself via method swizzling into several functions responsible for opening resources in response to the user clicking on a link once it was installed. This allowed Mintegral to track all URLs accessed by the user and report the data back to Mintegral’s servers. This has impacted millions of consumers to date.
  • Advertising attribution fraud SourMint was hijacking competing ad networks and consumers by manipulating click notifications used in attribution for app installs that were not actually generated by the Mintegral advertising platform. This process tricked attribution platforms to associate an install created by another source to Mintegral – manipulating the ‘last click attribution model’ commonly applied by attribution providers. This likely impacted the business of other advertisers and developers by taking away value that should have been attributed to them.

“As the first malicious SDK of this kind to infiltrate the iOS ecosystem, SourMint was very sophisticated. It avoided detection for so long by utilizing various obfuscations and anti-debugging tricks,” said Danny Grander, CSO, Snyk. “Developers were unaware of the malicious package upon deploying the application, allowing it to proliferate for more than a year. As cyber risk continues to ramp up, it’s critical for all software developers to mitigate the potential of malicious code making it into production and creating consumer privacy risk at this scale.”

Apple delivers March 2020 security updates for iDevices and software

If you haven’t yet opted for automatic Apple security updates, it’s time to update your iDevices and software again.

Apple security March 2020

The lightweight Apple security updates

The security update for Xcode – an integrated development environment for macOS containing a suite of software development tools developed by Apple for developing software for macOS, iOS, iPadOS, watchOS, and tvOS – offers no details about fixed security issues.

The iCloud (1, 2) and iTunes for Windows updates contain the same fixes:

  • Three buffer overflow flaws in libxml2, a software library for parsing XML documents
  • Ten security vulnerabilities in the WebKit browser engine, six of which could lead to arbitrary code execution if maliciously crafted web content is processed.

The tvOS update contains all those fixes, plus patches for a few kernel flaws, several vulnerabilities that could allow a malicious application to execute arbitrary code with system privileges, and one vulnerability stemming from poor handling of icon<</strong> caches that could be exploited by a malicious application to identify what other applications a user has installed.

The watchOS update also fixes that last flaw, as well as some of the three libxml2 vulnerabilities, several of the code execution flaws affecting WebKit, the kernel security holes, and a logic issue affecting Messages, which could allow a person with physical access to a locked device to respond to messages even when replies are disabled.

The heftier updates

iOS 13.4 and iPadOS 13.4 bring, among other things, fixes for:

  • The aforementioned WebKit, libxml2, kernel and Icon flaws
  • CVE-2020-9770, a logic issue that could allow an attacker in a privileged network position to intercept Bluetooth traffic
  • The aforementioned flaw affecting the privacy of Messages on a locked device
  • A flaw in Mail that could allow a local user to view deleted content in the app switcher
  • Two Safari flaws, one of which could make users grant website permissions to a site they didn’t intend to
  • A WebApp flaw that could allow a maliciously crafted page to interfere with other web contexts

Safari 13.1 delivers all the WebKit fixes and plugs a hole that could allow a malicious iframe to use another website’s download settings. (With Safari 13.1, Apple also started blocking third-party cookies.)

The macOS security updates (macOS Catalina 10.15.4, Security Update 2020-002 Mojave, Security Update 2020-002 High Sierra) fix a wider variety of flaws, including:

  • Those already mentioned in libxml2, kernel, icons
  • Bluetooth vulnerabilities that could allow a malicious application to read restricted memory or execute arbitrary code with kernel privileges
  • CVE-2020-9776, a flaw that could allow a malicious application to access a user’s call history
  • Several flaws that could allow an application to gain elevated privileges
  • An injection issue affecting Mail that could allow a remote attacker to cause arbitrary javascript code execution
  • A sudo issue that could allow an attacker to run commands as a non-existent user
  • CVE-2020-3906, a vulnerability that could allow a maliciously crafted application to bypass code signing enforcement.

iDevices finally get key-based protection against account takeovers

iDevices finally get key-based protection against account takeovers

For the past couple of years, iPhone and iPad users have been relegated second-class citizens when it comes to a cross-industry protocol that promises to bring effective multi-factor authentication to the masses. While Android, Windows, Mac, and Linux users had an easy way to use the fledgling standard when logging in to Google, GitHub, and dozens of other sites, the process on iPhones and iPads was either painful or non-existent.

Apple’s reticence wasn’t just bad for iPhone and iPad users looking for the most effective way to thwart the growing scourge of account takeovers. The hesitation was bad for everyone else, too. With one of the most important computing platforms giving the cold shoulder to WebAuthn, the fledgling standard had little chance of gaining critical mass.

And that was unfortunate. WebAuthn and its U2F predecessor are arguably the most effective protection against the growing rash of account takeovers. They require a person logging in with a password to also present a pre-enrolled fingerprint, facial scan, or physical security key. The setup makes most existing types of account takeovers impossible, since they typically rely solely on theft of a password.

Developed by the cross-industry FIDO alliance and adopted by the World Wide Web consortium in March, WebAuthn has no shortage of supporters. It has native support in Windows, Android, Chrome, Firefox, Opera, and Brave. Despite the support, WebAuthn has gained little more than niche status to date, in part because of the lack of support from the industry’s most important platform.

Now, the standard finally has the potential to blossom into the ubiquitous technology many have hoped it would become. That’s because of last week’s release of iOS and iPadOS 13.3, which provide native support for the standard for the first time.

More about that later. First, a timeline of WebAuthn and some background.

In the beginning

The handheld security keys at the heart of the U2F standard helped prepare the world for a new, superior form of MFA. When plugged into a USB slot or slid over an NFC reader, the security key transmitted “cryptographic assertions” that were unique to that key. Unlike the one-time passwords used by MFA authenticator apps, the assertions transmitted by these keys couldn’t be copied or phished or replayed.

U2F-based authentication was also more secure than one-time passwords because, unlike the authenticator apps running on phones, the security keys couldn’t be hacked. It was also more reliable since keys didn’t need to access an Internet connection. A two-year study of more than 50,000 Google employees a few years ago concluded that cryptographically based Security Keys beat out smartphones and most other forms of two-factor verification.

U2F, in turn, gave way to WebAuthn. The new standard still allows cryptographic keys that connect by USB or NFC. It also allows users to provide an additional factor of authentication using fingerprint readers or facial scanners built into smartphones, laptops, and other types of hardware the user already owns.

A plethora of app, OS, and site developers soon built WebAuthn into their authentication flows. The result: even when a password was exposed through user error or a database breach, accounts remained protected unless a hacker with the password passed the very high bar of also obtaining the key, fingerprint, or facial scan.

As Google, Microsoft, key maker Yubico, and other WebAuthn partners threw their support behind the new protocol, Apple remained firmly on the sidelines. The lack of support in macOS wasn’t ideal, but third-party support from the Chrome and Firefox browsers still gave users an easy way to use security keys. Apple’s inaction was much more problematic for iPhone and iPad users. Not only did the company provide no native support for the standard, it was also slow to allow access to near-field communication, a wireless communication channel that makes it easy for security keys to communicate with iPhones.

Poor usability and questionable security

Initially, the only way iPhones and iPads could use WebAuthn was with a Bluetooth-enabled dongle like Google’s Titan security key. It worked—technically—but it came with deal-breaking limitations. For one, it worked solely with Google properties. So much for a ubiquitous standard. Another dealbreaker—for most people, anyway—the installation of a special app and the process of pairing the keys to an iPhone or iPad was cumbersome at best.

Then in May, Google disclosed a vulnerability in the Bluetooth Titan. That vulnerability made it possible for nearby hackers to obtain the authentication signal as it was transmitted to an iPhone or other device. The resulting recall confirmed many security professionals’ belief that Bluetooth lacked the security needed for MFA and other sensitive functions. The difficulty of using Bluetooth-based dongles, combined with the perception that they were less secure, made them a non-starter for most users.

In September, engineers from authentication key-maker Yubikey built a developer kit that added third-party programming interfaces for WebAuthn. The effort was valiant, but it was also kludgey, so much so that the fledgling Brave browser was the only one to make use of it. Even worse, Apple’s steadfast resistance to opening up third-party access to NFC meant that the third-party support was limited to physical security keys that connected through the Lightning port or Bluetooth.

NFC connections and biometrics weren’t available. Worst of all, the support didn’t work with Google, Facebook, Twitter, and most other big sites.

iPhones and iPads finally get key-based protection against account takeovers

iPhones and iPads finally get key-based protection against account takeovers

For the past couple of years, iPhone and iPad users have been relegated to second-class citizenship when it comes to a cross-industry protocol that promises to bring effective multi-factor authentication to the masses. While Android, Windows, Mac, and Linux users had an easy way to use the fledgling standard when logging in to Google, GitHub, and dozens of other sites, the process on iPhones and iPads was either painful or non-existent.

Apple’s reticence wasn’t just bad for iPhone and iPad users looking for the most effective way to thwart the growing scourge of account takeovers. The hesitation was bad for everyone else, too. With one of the most important computing platforms giving the cold shoulder to WebAuthn, the fledgling standard had little chance of gaining critical mass.

And that was unfortunate. WebAuthn and its U2F predecessor are arguably the most effective protection against the growing rash of account takeovers. They require a person logging in with a password to also present a pre-enrolled fingerprint, facial scan, or physical security key. The setup makes most existing types of account takeovers impossible, since they typically rely solely on theft of a password.

Developed by the cross-industry FIDO alliance and adopted by the World Wide Web consortium in March, WebAuthn has no shortage of supporters. It has native support in Windows, Android, Chrome, Firefox, Opera, and Brave. Despite the support, WebAuthn has gained little more than niche status to date, in part because of the lack of support from the industry’s most important platform.

Now, the standard finally has the potential to blossom into the ubiquitous technology many have hoped it would become. That’s because of last week’s release of iOS and iPadOS 13.3, which provide native support for the standard for the first time.

More about that later. First, a timeline of WebAuthn and some background.

In the beginning

The handheld security keys at the heart of the U2F standard helped prepare the world for a new, superior form of MFA. When plugged into a USB slot or slid over an NFC reader, the security key transmitted “cryptographic assertions” that were unique to that key. Unlike the one-time passwords used by MFA authenticator apps, the assertions transmitted by these keys couldn’t be copied or phished or replayed.

U2F-based authentication was also more secure than one-time passwords because, unlike the authenticator apps running on phones, the security keys couldn’t be hacked. It was also more reliable since keys didn’t need to access an Internet connection. A two-year study of more than 50,000 Google employees a few years ago concluded that cryptographically based Security Keys beat out smartphones and most other forms of two-factor verification.

U2F, in turn, gave way to WebAuthn. The new standard still allows cryptographic keys that connect by USB or NFC. It also allows users to provide an additional factor of authentication using fingerprint readers or facial scanners built into smartphones, laptops, and other types of hardware the user already owns.

A plethora of app, OS, and site developers soon built WebAuthn into their authentication flows. The result: even when a password was exposed through user error or a database breach, accounts remained protected unless a hacker with the password passed the very high bar of also obtaining the key, fingerprint, or facial scan.

As Google, Microsoft, key maker Yubico, and other WebAuthn partners threw their support behind the new protocol, Apple remained firmly on the sidelines. The lack of support in macOS wasn’t ideal, but third-party support from the Chrome and Firefox browsers still gave users an easy way to use security keys. Apple’s inaction was much more problematic for iPhone and iPad users. Not only did the company provide no native support for the standard, it was also slow to allow access to near-field communication, a wireless communication channel that makes it easy for security keys to communicate with iPhones.

Poor usability and questionable security

Initially, the only way iPhones and iPads could use WebAuthn was with a Bluetooth-enabled dongle like Google’s Titan security key. It worked—technically—but it came with deal-breaking limitations. For one, it worked solely with Google properties. So much for a ubiquitous standard. Another dealbreaker—for most people, anyway—the installation of a special app and the process of pairing the keys to an iPhone or iPad was cumbersome at best.

Then in May, Google disclosed a vulnerability in the Bluetooth Titan. That vulnerability made it possible for nearby hackers to obtain the authentication signal as it was transmitted to an iPhone or other device. The resulting recall confirmed many security professionals’ belief that Bluetooth lacked the security needed for MFA and other sensitive functions. The difficulty of using Bluetooth-based dongles, combined with the perception that they were less secure, made them a non-starter for most users.

In September, engineers from authentication key-maker Yubikey built a developer kit that added third-party programming interfaces for WebAuthn. The effort was valiant, but it was also kludgey, so much so that the fledgling Brave browser was the only one to make use of it. Even worse, Apple’s steadfast resistance to opening up third-party access to NFC meant that the third-party support was limited to physical security keys that connected through the Lightning port or Bluetooth.

NFC connections and biometrics weren’t available. Worst of all, the support didn’t work with Google, Facebook, Twitter, and most other big sites.

Apple’s new Screen Time Communication Limits are easily beaten with a bug

iOS 13 on an iPhone 11 Pro.

Enlarge / iOS 13 on an iPhone 11 Pro.
Samuel Axon

A bug in iOS 13.3 allows children to easily circumvent the restrictions their parents or guardians set with the Communications Limit feature in Screen Time. Apple has said it plans to fix the problem in a future software update.

The iOS 13.3 update released earlier this week added the ability for parents to whitelist contacts for their kids to communicate with. Kids need the parents to input a passcode to talk to anyone not on the list, with an exception made for emergency services like 911. It was the flagship feature of the update.

Yesterday, CNBC published a report detailing a bug that allowed kids to easily circumvent the restrictions. It turns out that when contacts are not set to sync with iCloud by default, texts or calls from unknown numbers present children with the option to add the number as a new contact. Once that step has been taken, they can communicate freely with the contact.

Further, kids with access to an Apple Watch can ask Siri on the Watch to text or call a number on the paired iPhone, regardless of whether the number is whitelisted or not. CNBC notes that this does not work when Downtime, another parental control feature, is enabled, however.

Apple offered the following statement to CNBC as news of the issue spread:

This issue only occurs on devices set up with a non-standard configuration, and a workaround is available. We’re working on a complete fix and will release it in an upcoming software update.

Apple has faced a generally rocky launch with iOS 13 and its numerous subsequent smaller updates, such that the company has made plans to change how it tests and builds new software internally to avoid future problems. Our earlier report on that noted that sources close to Apple said the company had been happier with its software since the release of iOS 13.2. However, iOS 13.2 had a widespread memory issue affecting background apps, and iOS 13.3 now has this new ScreenTime issue, meaning the two recent feature updates each came with a major bug.

Apple has released more bug fix updates since the iOS 13 launch than is usual after an annual update.

Apple releases macOS Catalina 10.15.2, iOS, and iPadOS 13.3

The 2019 16-inch MacBook Pro with the lid closed

Enlarge / The 2019 16-inch MacBook Pro.
Samuel Axon

As has become a custom, Apple has simultaneously released software updates for nearly its entire suite of consumer products today—including iOS 13.3, iPadOS 13.3, macOS Catalina 10.15.2, watchOS 6.1.1, tvOS 13.3—and an update for HomePods. All updates should be available to all users by the end of the day.

iOS 13.3 and iPadOS 13.3 together make for arguably the most notable update. They introduce yet another feature that was originally pitched by Apple as part of iOS 13 but was delayed before that annual update’s release this September: Communication Limits in ScreenTime. Parents can now whitelist contacts for their kids’ accounts, which allows them to block their kids from communicating with anyone outside the list on Apple-made apps like Messages and FaceTime, with exceptions for emergency calls and services like 911.

These two updates also introduce new layouts for certain publications in Apple News+, adds a new interface for liking or disliking stories in News, and expands on the news options and coverage in the Stocks app.

macOS Catalina 10.15.2 gets most of these same News and Stocks features, plus the restoration of the column browser view in Apple Music and the addition of Apple Remote app support for the Music and TV apps on Macs.

Additionally, tvOS 13.3 is a somewhat notable update for recent Apple TV streaming boxes. It includes a slight homescreen redesign for video previews as well as a change to the top shelf of content visible on that screen. Whereas it previously showed you the next items in your TV app queue while that app was selected, it will now recommend new content there by displaying trailers and previews. However, an option has been adding to settings to let you switch back to the old way.

Today’s HomePod update improves voice recognition for family members and “allows individual family members to enable/disable personal requests.” watchOS 6.1.1 is a minor update that contains unspecified bug fixes and optimizations. Apple also released a security update for watchOS 5 for users who do not have an iPhone capable of running iOS 13, as watchOS 6 requires the latest iPhone software.

All of the updates today also have a plethora of bug fixes and security updates for their respective platforms, which you can find in Apple’s release notes below.

iOS and iPadOS 13.3 release notes

iOS 13.3 includes improvements, bug fixes, and additional parental controls for Screen Time.

Screen Time

  • New parental controls provide more communication limits over who their children can call, FaceTime, or Message
  • Contact list for children lets parents manage the contacts that appear on their children’s devices

Apple News

  • New layout for Apple News+ stories from The Wall Street Journal and other leading newspapers
  • Easily like or dislike stories with a tap

Stocks

  • Stories from Apple News are now available in Canada in English and French
  • Continue reading with links to related stories or more stories from the same publication
  • Breaking and Developing labels for Top Stories

This update also includes bug fixes and other improvements. This update:

  • Enables the creation of a new video clip when trimming a video in Photos
  • Adds support for NFC, USB, and Lightning FIDO2-compliant security keys in Safari
  • Fixes issues in Mail that may prevent downloading new messages
  • Addresses an issue that prevented deleting messages in Gmail accounts
  • Resolves issues that could cause incorrect characters to display in messages and duplication of sent messages in Exchange accounts
  • Fixes an issue where the cursor may not move after long-pressing on the space bar
  • Addresses an issue that may cause screenshots to appear blurry when sent via Messages
  • Resolves an issue where cropping or using Markup on screenshots may not save to Photos
  • Fixes an issue where Voice Memos recordings may not be able to be shared with other audio apps
  • Addresses an issue where the missed call badge on the Phone app may not clear
  • Resolves an issue where the Cellular Data setting may incorrectly show as off
  • Fixes an issue that prevented turning off Dark Mode when Smart Invert was enabled
  • Addresses an issue where some wireless chargers may charge more slowly than expected

What the newly released Checkra1n jailbreak means for iDevice security

What the newly released Checkra1n jailbreak means for iDevice security

It has been a week since the release of Checkra1n, the world’s first jailbreak for devices running Apple’s iOS 13. Because jailbreaks are so powerful and by definition disable a host of protections built into the OS, many people have rightly been eyeing Checkra1n—and the Checkm8 exploit it relies on—cautiously. What follows is a list of pros and cons for readers to ponder, with a particular emphasis on security.

The good

First, Checkra1n is extremely reliable and robust, particularly for a tool that’s still in beta mode. It jailbreaks a variety of older iDevices quickly and reliably. It also installs an SSH server and other utilities, a bonus that makes the tool ideal for researchers and hobbyists who want to dig into the internals of their devices.

“I expected it to be a little rougher around the edges for the first release,” Ryan Stortz, an iOS security expert and principal security researcher at the firm Trail of Bits, said in an interview. “It’s really nice to be able to install a new developer beta on your development iPhone and have all your tooling work out of the box. It makes testing Apple’s updates much much easier.”

Another benefit of Checkra1n is that it promises to work reliably on a wide array of hardware. Those models include devices from the iPhone 5s all the way to the iPhone X running iOS 12.3 or later. (At the moment, the Checkra1n beta doesn’t support the iPad Air 2, first generation iPad Pro, and fifth generation iPad. Users may also experience problems when running this beta on the iPhone 5s, iPad mini 2, and iPad mini 3. These incompatibilities will likely be fixed in time, as new Checkra1n updates become available.)

Also significant, Checkm8-based jailbreaks will work permanently on these devices. Unlike most jailbreaks, which exploit vulnerabilities in iOS, Checkm8 targets a flaw in the Boot ROM, which is the first code that runs when an iDevice is turned on. This code is burned into the hardware itself and can’t be patched. This is the reason Checkra1n will work with every new release of iOS over the lifetime of a vulnerable phone.

This means that people can continue to enjoy the benefits and security fixes available in new iOS releases without losing the ability to jailbreak their devices (new versions of iOS inevitably fix jailbreaking vulnerabilities). This is a far cry from jailbreaks over the past decade that forced users to run outdated versions of iOS. The last time a jailbreak targeted the Boot ROM was in 2010 when hacker George Hotz (aka Geohot) developed one for the iPhone 3GS and iPhone 4.

Checkra1n is also helpful because it makes it painfully obvious it has been used. A large Checkra1n logo displays during bootup. And the home screen will include the Cydia and Checkra1n apps, neither of which appear when an iDevice runs normally.

And like all Checkm8-based jailbreaks, Checkra1n requires physical access to the vulnerable device and a reboot, which means user data and Touch ID and Face ID are inaccessible until the next time a PIN is entered to unlock the device. This means that remote exploits aren’t possible.

The bad

Checkm8-based jailbreaks, including Checkra1n, come with some notable limitations that many jailbreaking enthusiasts consider deal-breakers. First, Checkm8 doesn’t work on iDevices introduced in the past two years, specifically those with A12 and A13 CPUs. That limits the jailbreak to older devices, most of which—but not all—are no longer sold in retail outlets.

The other major limitation is that Checkm8-based jailbreaks are “tethered,” meaning they don’t survive a reboot. Each time the device is restarted, it must first be connected to a Mac—eventually Windows versions of Checkra1n are expected—and jailbroken all over again. Untethered jailbreaks, by contrast, are much more popular because they allow iDevices to boot normally, without being connected to a computer each time.

Another drawback to any jailbreak is that it’s an inevitably risky thing, since it unbinds an iDevice from the protections and quality assurances Apple has painstakingly built into iOS over more than a decade. Apple warns here that jailbreaking can “cause security vulnerabilities, instability, shortened battery life, and other issues.” The stakes are raised further by the beta status of Checkra1n. The Checkra1n website warns: “This release is an early beta preview and as such should not be installed on a primary device. We strongly recommend proceeding with caution.”

Then there are the risks of error by inexperienced users who are drawn to Checkra1n’s reliability, robustness, and its promise to work—on older devices, anyway—in perpetuity.

“The biggest threat from Checkra1n is how easily a non-technical user can jailbreak their device, which then leaves it vulnerable to additional attacks,” Christoph Hebeisen, head of security research at mobile security provider Lookout, said. One protection that Checkra1n deactivates is the iOS sandbox, which cordons off sensitive parts of iOS from the apps it runs. The risk is heightened by the ability of jailbroken devices to run any app. Normally iPhones and iPads can run only apps that are available in the App Store, which vets submissions for security and stability before allowing them in.

One other warning: the site checkrain[.]com is an imposter site that installs a malicious profile onto the end-user device. Readers should steer clear.

The (more subtly) bad

There’s a more subtle threat posed by Checkra1n’s ease in almost completely unpairing a device from the protections that have made iOS arguably the world’s most secure OS. As noted earlier, it would be hard for someone to use this jailbreak maliciously against someone else. But Stortz, the iOS security expert at Trail of Bits, said that Checkra1n’s release demonstrates just how powerful it could be should its capabilities fall into the wrong hands.

“The threat is more real now because a sophisticated exploit is available to everyone,” he said. He went on to theorize cases of attackers reverse-engineering Checkra1n and combining its jailbreaking capabilities with rootkits or other malicious code. All attackers might need to use this malicious Checkra1n-derived jailbreak is very brief access to an iDevice. This type of attack could covertly steal text messages, login credentials, cryptographic keys, and all kinds of other sensitive data. These attacks would be particularly effective against iPhones and iPads that don’t use fingerprints or face scans for unlocking. He explained:

Checkm8 allows someone to undermine the trust of the iOS secure boot chain. Checkra1n makes it easy to do. It’s true that checkra1n puts a nice logo on it and installs development tools, but that doesn’t need to happen. Someone will modify checkra1n to remove the logo and install a rootkit instead. [In that scenario] having a PIN-only passcode is a poor choice. You’ll pick up your phone [after Checkra1n is surreptitiously installed] and unlock it, allowing the rootkit full access to your personal data.

It has been possible to create this type of malicious jailbreak since late September, when the Checkm8 exploit became public. But that kind of attack required huge amounts of time and skill. Now, Stortz said, “no one would do that when Checkra1n exists and is so well done.”

The take-away from the sort of scenario Stortz hypothesizes is this: for journalists, dissidents, and other high-value targets who use iOS devices and can afford to, it’s best to use hardware that has an A12 or higher CPU. An iDevice introduced in the past two years will ensure that it’s safe from Checkra1n-derived attacks at border crossings, in hotel rooms, or in other situations that involve brief separations.

For iOS users who can’t afford a newer iPhone or iPad, using Touch ID or Face ID can lower the chances of malicious jailbreaks since users can be tipped off that something is amiss if the iDevice unexpectedly requires a PIN. And whenever the device has been out of the user’s control, even briefly—or users suspect anything else is amiss—they should reboot it.

This level of scrutiny is probably overkill for most users of vulnerable iPhones and iPads. Unfortunately, for users belonging to more targeted groups, these precautions are a natural consequence of a post-Checkra1n era.