MacInTouch Amazon link...

Apple security and privacy

Channels
Apple, Security
The Windows version of iTunes includes an embedded implementation of SQLite, because Windows does not have a system implementation of SQLite. macOS iTunes uses the system-provided SQLite.
Yes, and no. Windows 7, which iTunes still supports, does not have a system implementation of SQLite but Microsoft is updating SQLite in Windows 10, and that relieves developers of the need to update their applications in response to SQLite updates. Should make the developer's life easier, and possibly make applications that use SQLite to store data safer.
Windows (.com) said:
Using SQLite databases in UWP apps
Since the Windows 10 Anniversary Update (Build 14393), SQLite has also shipped as part of the Windows SDK. . . . This comes with some advantages:
  • Your application size reduces since you don’t download your own SQLite binary and package it as part of your application . . .
  • You can depend on the Windows team to update the version of SQLite running on the operating system with every release of Windows.
Over on our Mac side of the fence, if there are Mac applications that "call" the embedded 3.16 SQLite in Sierra, then add their own FTS3 plugin, those developers would have to go further, disconnect from the 3.16 version in Sierra, and package SQLite into their applications. Not going to happen with the black crepe for Sierra already on order.

As to Todd's comments that the listed versions of iTunes with SQLite vulnerabilities were "Windows only", iTunes 12.8 is listed. There's a Windows 12.8 and, apparently, a Mac 12.8. Confusion reigns, when I'd like certainty on security issues.
The Mac Observer said:
Apple Releases iTunes 12.8 with AirPlay 2 Support (July 10, 2018)
Along with macOS High Sierra 10.13.6, Apple released iTunes 12.8 . . .
Even as I was typing this post, Ric added more about macOS vulnerabilities, the most stunning the hack into Keychain on Mojave 10.14.3 - with an app that looks a lot like an SQLite interface (?).

Another undocumented update to Apple's invisible anti-malware mechanism: . . . it now obfuscates the names of malware which it can detect and remove
That obfuscation is classic Apple secrecy-obsession. It won't keep "bad guys" from testing their malware against a patched Mac, but it doesn't allow end-users to know if Macs are vulnerable to the latest known threats. Be interesting to know if developers of known applications like Malwarebytes are informed by Apple what MRT is blocking. Might save duplicate work, and avoid complications when two different applications are trying to intercept the same malware.

Wander thorough Apple's "security pages" and in a couple of clicks you'll confront the one security Mac recommendation highlighted above all others: "Upgrade to Mojave 10.14.3"

Could it be that the keychain on my MacBook Pro orphaned on El Capitan is safer than on the latest version of Mojave?
 


When I tried to set up an iPhone SE last year (after having purchased and set up many iPhones over many years previously), it was an unmitigated disaster ... I don't know if iMazing was my best option, though, and I was surprised at having to download all the apps again wirelessly and reconfigure a number of things I had already configured on this new phone once. iMazing "erased" the iPhone as part of its restore process, so that may have wiped out all the identity data and settings I'd already added to the new phone....)
Ack, that sounds painful! About two weeks ago, I got a new iPad and wondered how to set it up and get my old iPad Air data on it efficiently. I found that Apple now has instructions for switching to a new device. There are three methods so I tried transfer using Quick Start, which worked amazingly well. Everything (apps, data, mail accounts - except passwords) transferred and looked much as my old iPad.

However, one of my email signatures was wrong, so I tried to correct it, but the Mail setting kept crashing each time I tapped it. I tried reset all contents to no avail. Thinking it was a random transfer glitch, I erased all content and did the quick start again, but the problem persisted.

Then I thought to erase and try "Transfer using iCloud/iTunes" but wonder if the glitch resides in the backups. I spoke with Apple Support, who said it probably would be in the backup. So, I could erase and start from the very beginning or do a quick start using my iPhone. I did the latter, and all apps (and some data) transferred over. None of the mail accounts info transferred.

Although I have more and some different apps on my iPhone than iPad, this setup method worked for me. I think the original glitch might have to do with the iPad Air being 5+ years old. Oh, the new iPad Pro works with iTunes 12.6.5. I hope this helps, and your milage may vary.
 


I had not realized that Apple does not have a bounty program for reporting macOS bugs, only for iOS.
Engadget said:
Researcher finds macOS bug but won’t share details with Apple
Yet Henze won't help Apple patch the exploit because its bug bounty program only pays out to researchers for disclosing bugs on iOS and not macOS. "It's like they don't really care about macOS," he told Forbes. "Finding vulnerabilities like this one takes time, and I just think that paying researchers is the right thing to do because we're helping Apple to make their product more secure."
Forbes said:
Teenage Hacker's Evil App Steals Apple Mac Passwords
Henze found he could create an app that was able to read what was in the keychain without requiring explicit permission from the victim. His mock malware didn’t require special privileges, like administrator-level permissions. “Running a simple app is all that’s required,” Henze said.
As for how the malware could get onto the Mac in the first place, a malicious hacker could hide the keychain exploit in a legitimate app, Henze hypothesized. Or a user could be directed to a webpage that would launch rogue code. And because the attack could grab tokens for accessing the iCloud, it would be possible to take over an Apple ID and download they keychain from the company’s servers, said Henze.
...Forbes had Apple Mac security specialist Patrick Wardle test the exploit. Wardle, a former NSA analyst, was impressed with the young researcher’s find. “Big kudos to Linus. It’s a really lovely bug," he said, joking that “until Apple wraps its head around security, I’m shutting off my Mac and going surfing.
 


Ric Ford

MacInTouch
And the hits just keep coming...
TechCrunch said:
Many popular iPhone apps secretly record your screen without asking
Many major companies, like Air Canada, Hollister and Expedia, are recording every tap and swipe you make on their iPhone apps. In most cases you won’t even realize it. And they don’t need to ask for permission.

... The App Analyst, a mobile expert who writes about his analyses of popular apps on his eponymous blog, recently found Air Canada’s iPhone app wasn’t properly masking the session replays when they were sent, exposing passport numbers and credit card data in each replay session. Just weeks earlier, Air Canada said its app had a data breach, exposing 20,000 profiles.

“This gives Air Canada employees — and anyone else capable of accessing the screenshot database — to see unencrypted credit card and password information,” he told TechCrunch.

... Apps that are submitted to Apple’s App Store must have a privacy policy, but none of the apps we reviewed make it clear in their policies that they record a user’s screen. Glassbox doesn’t require any special permission from Apple or from the user, so there’s no way a user would know.
 


Ric Ford

MacInTouch
The all-important Apple Keychain apparently has a big, unpatched vulnerability:
Teenage Hacker's Evil App Steals Apple Mac Passwords
Here's more about stunning Apple security failures that expose customers' most critical passwords, which Apple claimed to be protecting:
Bleeping Computer said:
Researcher Declines to Share Zero-Day macOS Keychain Exploit with Apple

... This is not the first time a zero-day macOS keychain exploit was found, with Patrick Wardle, a former NSA hacker, also demoing a similar vulnerability called KeychainStealer a year ago, which Apple eventually patched after the researcher reported the bug prior to the release of macOS 10.13 High Sierra.

Unfortunately, the fix for the keychain security flaw Wardle reported did not make it in the official High Sierra release.

Wardle previously found another zero-day which would allow attackers to bypass the new "Secure Kernel Extension Loading" (SKEL) feature added in macOS High Sierra, allow them to load malicious kernel extensions and completely take over the Mac.

After being asked by BleepingComputer if he tested Henze's exploit, Wardle stated that:
Yes, I was able to test it on a fully patched system and it worked lovely… It’s a really nice bug inspiringly so... If I’m a hacker or piece of malware this would be the first thing I do once I gain access to the system… Dump various keychains to extract passwords private keys signing certificates and sensitive tokens. It’s unfortunate that there is yet another bug in the keychain access… One would hope something like a keychain which is supposed to be secure would, in fact, be secure but unfortunately, that’s not the case.
 


Ric Ford

MacInTouch
Apple "forgot" to mention in its iOS 12.1.4 security update notes that the patched vulnerabilities are being actively exploited in the wild... which suggests that iPhones should be updated as soon as possible.
ZDNet said:
Google warns about two iOS zero-days 'exploited in the wild'
A Google top security engineer has revealed today that hackers have been launching attacks against iPhone users using two iOS vulnerabilities. The attacks have happened before Apple had a chance to release iOS 12.1.4 today --meaning the two vulnerabilities are what security experts call "zero-days."

... This release also fixes the infamous FaceTime bug that allowed users to eavesdrop on others using group FaceTime calls.
Unfortunately, it appears that the gross Keychain failure is still unpatched. Locking the Keychain with a password other than your login password may help with that at the cost of convenience.
 


Setting up a new iPhone SE:
  • requires SIM card and Apple ID/password for activation (I didn't try doing it through iTunes without a SIM card)
  • connects to old iPhone via Bluetooth enabled on both, using trippy, moving blue cloud image (what is this?) on old iPhone and camera on new iPhone to transfer a few settings (Apple ID, WiFi)
  • requires updating to iOS 12.1.3 in order to restore my backup (via iMazing), something I did not want to do but can't see how to avoid
  • requires re-entering credit card info for Apple Pay (security code for Apple Store credit card)
  • After restoring a backup of my other phone, iOS demands credentials and security question answers and 2FA codes for an entirely different Apple ID that's not associated with this phone but used only for email - very confusing.
  • Restoring the backup left all the apps unrestored, so the iPhone itself is now... very... slowly... downloading... all of those.
  • Restoring the backup wiped out the Apple Pay and fingerprint data I'd just entered previously.
  • Apple turned Game Center on for iCloud when it had been off.
I finally found some time to activate the iPhone SE that was delivered several days ago.
  • Transfer SIM from iPhone 5S to SE
  • Skip "Quick Start" and select "Set up manually" instead
  • Set up "Touch ID later"
  • Set up Passcode
  • Select "Restore from iTunes Backup"
  • Connect phone via USB to iTunes (v12.6.5.3)
  • Set up as "New" or "Restore". Defaulted to Restore and accepted.
  • FAILED. Error message: "The backup "myPhone" cannot be restored to this iPhone because the software on the iPhone is too old. To restore this iPhone from this backup, you must first set up the iPhone as new and restore the software to the latest version."
  • iTunes downloads iOS 12.1.4.
  • Downloading...Extracting...Preparing for update...Waiting for iPhone... Verifying... Updating iPhone software...Verifying updated iPhone Software...Updating iPhone firmware...Your iPhone has been updated and is restarting...etc...
  • Select "Restore Backup" in iTunes and backup was restored this time
  • Another restart
  • "Press Home to Upgrade" (upgrade what? Didn't we just do that?)
  • Another restart
  • Restore completed. Just a few more steps...
  • Done. I think. Whew!
I'm using iTunes 12.6.5.3 so all apps were restored from the local version—no downloading was required. No Apple ID was required. Some settings were reset to Apple defaults.

This is the first time that I've upgraded/replaced an iOS device so I wasn't certain what to expect—and ended up documenting all the steps.
 


"Press Home to Upgrade" (upgrade what? Didn't we just do that?)
When you make the backup, the settings associated with it are for the version of iOS that the backup was made on. In this case, I'm assuming it was iOS <12.1.4. Normally, any settings and stuff like that that needs updating takes place when you do the iOS upgrade, for example from 12.1.3 to 12.1.4.

Since you restored from an older iOS backup onto 12.1.4, all those settings need to go through the upgrade process to make sure they are set appropriately for 12.1.4.
 


Setting up a new iPhone SE:
  • requires SIM card and Apple ID/password for activation (I didn't try doing it through iTunes without a SIM card)
I noticed that starting from a recent (few months?) iOS upgrade, a SIM card is not needed anymore to setup a new iPhone even after full DFU restore of the unit.
Apps are not included in iOS backups, not even iTunes backups. What is included, is a record of which apps and versions were installed at the time of the backup, and after restoring a backup, iOS downloads those exact versions from the App Store (even apps that are no longer available for purchase) to the newly restored device. So, if new app versions have come out between the time when your backup was taken and when your restore was done, you will have updates available.
Are you sure? I'm convinced that only the latest version of the apps are being downloaded after a restore, and this can be a problem if the app is not available anymore on the App Store or if it's not updated to be compatble with the latest iOS installed.
 



I finally found some time to activate the iPhone SE that was delivered several days ago.
  • Transfer SIM from iPhone 5S to SE
  • Skip "Quick Start" and select "Set up manually" instead
  • Set up "Touch ID later"
  • Set up Passcode
  • Select "Restore from iTunes Backup"
  • Connect phone via USB to iTunes (v12.6.5.3)
  • Set up as "New" or "Restore". Defaulted to Restore and accepted.
  • FAILED. Error message: "The backup "myPhone" cannot be restored to this iPhone because the software on the iPhone is too old. To restore this iPhone from this backup, you must first set up the iPhone as new and restore the software to the latest version."
  • iTunes downloads iOS 12.1.4.
  • Downloading...Extracting...Preparing for update...Waiting for iPhone... Verifying... Updating iPhone software...Verifying updated iPhone Software...Updating iPhone firmware...Your iPhone has been updated and is restarting...etc...
  • Select "Restore Backup" in iTunes and backup was restored this time
  • Another restart
  • "Press Home to Upgrade" (upgrade what? Didn't we just do that?)
  • Another restart
  • Restore completed. Just a few more steps...
  • Done. I think. Whew!
I'm using iTunes 12.6.5.3 so all apps were restored from the local version—no downloading was required. No Apple ID was required. Some settings were reset to Apple defaults.

This is the first time that I've upgraded/replaced an iOS device so I wasn't certain what to expect—and ended up documenting all the steps.
For what it's worth, the process for setting up a new iPhone from an iTunes backup is documented in:
Apple said:
and the specific issue of what to do when a later version of iOS is required is covered in:
Apple said:
 


Ric Ford

MacInTouch
And the hits just keep coming...
And coming...
Bleeping Computer said:
Privacy Protection Bypass Flaw in macOS Gives Access to Browsing History
A macOS privacy protection bypass flaw could allow potential attackers to access data stored in restricted folders on all macOS Mojave release up to the 10.14.3 Supplemental Update released on February 7.

The privacy flaw was discovered by Mac and iOS developer Jeff Johnson on February 8, who received an automated bug report response after emailing a bug report to Apple Product Security on Saturday morning; an official response has not been issued yet.

A specially crafted application designed to take advantage of this macOS issue would allow an attacker to snoop on the contents of a potential victim's browsing history.

... On September 26 he unearthed another one which he eventually disclosed in November, after the release of macOS 10.14.1, that it was related to the Automator app.

... The Automator issue was fixed by Apple with the release of macOS Mojave 10.14.3 Supplemental Update on February 7, but the other two are still unpatched. Also, Jeff Johnson is still waiting for credit from Apple for his contributions.

Last week, security researcher Linus Henze also demoed a zero-day exploit affecting the macOS Keychain password management system that can store passwords for applications, servers, and websites, as well as sensitive information related to banking accounts.
 


Ric Ford

MacInTouch
Here's a new attack vector, leveraging a Trojan horse that pretends to be Little Snitch....
Dan Goodin/Ars Technica said:
Hackers keep trying to get malicious Windows file onto MacOS
Malware pushers are experimenting with a novel way to infect Mac users that runs executable files that normally execute only on Windows computers.

Researchers from antivirus provider Trend Micro made that discovery after analyzing an app available on a Torrent site that promised to install Little Snitch, a firewall application for macOS. Stashed inside the DMG file was an EXE file that delivered a hidden payload. The researchers suspect the routine is designed to bypass Gatekeeper, a security feature built into macOS that requires apps to be code-signed before they can be installed. EXE files don’t undergo this verification, because Gatekeeper only inspects native macOS files.

... In 2015, macOS security expert Patrick Wardle reported a drop-dead simple way for malware to bypass Gatekeeper. The technique worked by bundling a signed executable with a non-signed executable. Apple fixed the bypass weakness after Wardle reported it.
 


Ric Ford

MacInTouch
Here's a new attack vector, leveraging a Trojan horse that pretends to be Little Snitch....
Here's a good description of how this malware operates:
Bleeping Computer said:
Windows Malware Runs on Macs, Bypasses Gatekeeper to Target Software Pirates
If it wasn't already obvious, pirating software is a risky business and this was again proven by a set of malicious executables targeting macOS users with info stealers and adware, and compiled as Windows EXE binaries with the help of the open source Mono framework.

Mono is designed to allow developers to create cross-platform .NET applications part of the .NET Foundation, which can be later used on multiple platforms, from macOS, Windows, Android, most Linux distributions, BSD, and Solaris, as well as on some game consoles such as PlayStation, Xbox, and Wii.

The malware ridden executables discovered by Trend Micro's Don Ladores and Luis Magisa are distributed via torrent websites and promise to deliver cracked versions of various software:
  • Little_Snitch_583_MAC_OS_X.zip
  • Paragon_NTFS_for_Mac_OS_Sierra_Fully_Activated.zip
  • Wondershare_Filmora_924_Patched_Mac_OSX_X.zip
  • LennarDigital_Sylenth1_VSTi_AU_v3_203_MAC_OSX.zip
  • Sylenth1_v331_Purple_Skin__Sound_Radix_32Lives_v109.zip
  • TORRENTINSTANT.COM+-+Traktor_Pro_2_for_MAC_v321.zip
Mono-based binaries will launch unhindered as long as the Mono runtime is available on the system and the threat actors made sure that their malware will be able to run by bundling a copy of the Mono framework within the downloaded installers.

The installer within the Little_Snitch_583_MAC_OS_X.zip (the one Trend Micro chose to analyze) looks just like any other macOS app, but on closer inspection, when looking within the application bundles, the researchers were able to find the maliciously crafted EXE files which will deliver "a malicious payload that overrides Mac’s built-in protection mechanisms such as Gatekeeper."
 



I found an exploit in Gatekeeper that I'm not going to explain in detail here (it's in Apple's Bug Radar). It involves getting Gatekeeper to notify the user of an innocuous looking file type, and then launching in a different application with potentially dangerous results.

The problem at hand in the case of my discovery, and the mislabeled .exe files, is that Gatekeeper is a blacklist, not a whitelist, and it scans beforehand, not after the fact.

It doesn't know how to stop everything, just what it's told to stop - and it can't stop malicious acts in progress, like antivirus or anti-malware can. Apple makes the decisions on what it stops, and they have to tread a fine line between it nagging you to death about every image you download from Facebook and keeping you safe from the malicious ones.
 


Here's a good description of how this malware operates:
See this tweet:
Adam Thomas said:
https://twitter.com/adamt5six/status/1095373436711505921
It's not really a clever trick and it doesn't "bypass Gatekeeper" but whatever
and the comments to the referenced Ars Technica posting.
Thomas Reed said:
Technically, there’s no Gatekeeper bypass here. In fact, if you try to run that Installer app that contains the .exe, Gatekeeper will stop it. The Installer.exe would not be blocked by Gatekeeper even if it were a .app, since it’s being launched by the main Installer app.
And one more...
Patrick Wardle said:
https://twitter.com/patrickwardle/status/1095575330255908864
btw, there's no Gatekeeper bypass/issue! ????

The app's main binary is a standard (machO) binary that Gatekeeper validates & will block if unsigned/cert revoked.

Once user allows it to run, of course can load & execute a Mono/.Net assembly (e.g. Installer.exe) or anything else...
 


Ric Ford

MacInTouch
I tried unsuccessfully to do this with a 2018 MacBook Pro - boot repeatedly failed, in Kafka-like ways, even after turning off startup security and enabling external boot. (I can't even boot a current Linux Mint Live USB stick that works fine on several 2015 and older MacBook Pros. I think Apple may have killed Linux booting with a Mojave update at some point.)
I received an anonymous email about this, reminding me of an issue I'd forgotten:
My limited understanding of this issue is that even with startup security turned off Macs with T2 chips still require a signed OS to boot. It appears that Linux distros were and still are all using the same signature (one from Microsoft) to sign their OS. This of course defeats the whole purpose of signing. I came across something that said that Apple has blocked that particular sig (Microsoft has always used a different one to sign windows). Until and unless Linux distros obtain there own sigs I don't see this being resolved. Unless Apple caves which is not something they are well known for doing.

P.S. this is being sent from a MacBook 2,1 running Mint 19
 


I always figured this was inevitable but the process has started - received this from Apple this morning:
Apple said:
In an effort to keep your account more secure, two-factor authentication will be required to sign in to your Apple Developer account and Certificates, Identifiers & Profiles starting February 27, 2019.
I'm sure it's only a matter of time before 2FA is required on all accounts. What a PIA - I hate 2FA.
 


Ric Ford

MacInTouch
I tried unsuccessfully to do this with a 2018 MacBook Pro - boot repeatedly failed, in Kafka-like ways, even after turning off startup security and enabling external boot. (I can't even boot a current Linux Mint Live USB stick that works fine on several 2015 and older MacBook Pros. I think Apple may have killed Linux booting with a Mojave update at some point.)
I received an anonymous email about this, reminding me of an issue I'd forgotten:
My limited understanding of this issue is that even with startup security turned off Macs with T2 chips still require a signed OS to boot. It appears that Linux distros were and still are all using the same signature (one from Microsoft) to sign their OS. This of course defeats the whole purpose of signing. I came across something that said that Apple has blocked that particular sig (Microsoft has always used a different one to sign windows). Until and unless Linux distros obtain there own sigs I don't see this being resolved. Unless Apple caves which is not something they are well known for doing.
P.S. this is being sent from a MacBook 2,1 running Mint 19
And here are the details:
Phoronix said:
Apple's New Hardware With The T2 Security Chip Will Currently Block Linux From Booting
By default, Microsoft Windows isn't even bootable on the new Apple systems until enabling support for Windows via the Boot Camp Assistant macOS software. The Boot Camp Assistant will install the Windows Production CA 2011 certificate that is used to authenticate Microsoft bootloaders. But this doesn't setup the Microsoft-approved UEFI certificate that allows verification of code by Microsoft partners, including what is used for signing Linux distributions wishing to have UEFI SecureBoot support for Windows PCs.

Apple's T2 documentation makes it clear and explicitly mentions Linux:
NOTE: There is currently no trust provided for the the Microsoft Corporation UEFI CA 2011, which would allow verification of code signed by Microsoft partners. This UEFI CA is commonly used to verify the authenticity of bootloaders for other operating systems such as Linux variants.​
In other words, until Apple decides to add this certificate or the T2 chip otherwise is cracked so it could be fully disabled or allowed to load arbitrary keys, good luck even being able to boot Linux distributions on the new Apple hardware.

Update: According to Apple Support it may be possible to disable the Secure Boot security in full when booting to the Startup Security Utility in the macOS Recovery mode. This may allow Linux to then load on the device albeit without any boot security but by default / out-of-the-box the T2 chip will indeed prevent Linux distributions from booting.

Update 2: It looks like even if disabling the Secure Boot functionality, the T2 chip is reportedly still blocking operating systems aside from macOS and Windows 10.
 


I always figured this was inevitable but the process has started - received this from Apple this morning:
Apple said:
In an effort to keep your account more secure, two-factor authentication will be required to sign in to your Apple Developer account and Certificates, Identifiers & Profiles starting February 27, 2019.
I'm sure it's only a matter of time before 2FA is required on all accounts. What a PIA - I hate 2FA.
Apple is requiring 2FA in an apparent attempt to cut back App piracy. I suspect that other limitations to developer certs will follow.
CNBC/Reuters said:
Pirates found a way to load paid apps on iPhones for free, and Apple could be losing money
  • Software pirates have hijacked versions of legitimate apps, like Spotify, that users can install through a program meant only for businesses to use with their own employees, Reuters says.
  • The pirated apps deprive Apple and other app makers of revenue.
  • The pirates exploited the same Apple App Store rule that Facebook and Google apparently violated for their research-collection apps, as reported earlier this year.
... Apple confirmed a media report on Wednesday that it would require two-factor authentication — using a code sent to a phone as well as a password — to log into all developer accounts by the end of this month, which could help prevent certificate misuse....
 


I always figured this was inevitable but the process has started - received this from Apple this morning:
Apple said:
In an effort to keep your account more secure, two-factor authentication will be required to sign in to your Apple Developer account and Certificates, Identifiers & Profiles starting February 27, 2019.
I'm sure it's only a matter of time before 2FA is required on all accounts. What a PIA - I hate 2FA.
I agree. Apple should write an app that makes managing Apple ID and 2FA easier.
 


Ric Ford

MacInTouch
More major nastiness targeting Macs and faking Flash (while flaws in real Flash are also being exploited currently):
BleepingComputer said:
Shlayer Malware Disables macOS Gatekeeper to Run Unsigned Payloads
A new variant of the multi-stage Shlayer malware known to target macOS users has been observed in the wild, now being capable to escalate privileges using a two-year-old technique and to disable the Gatekeeper protection mechanism to run unsigned second stage payloads.

Shlayer was first observed in action by Intego's research team which found it being distributed as part of a malware campaign during February 2018, disguising as a fake Adobe Flash Player installer like many other malware families targeting the Mac platform.

Just like it did in the past, the new malware version is also distributed as a malicious Adobe Flash software update, but unlike the original version which was pushed through torrent websites, Shlayer is now spreading as fake update pop-ups on hijacked domains or legitimate sites clones, or as part of malvertising campaigns running on legitimate websites.

This new Shlayer variant unearthed by Carbon Black’s Threat Analysis Unit (TAU) targets all macOS releases up to the latest 10.14.3 Mojave, and will arrive on the targets' machines as a DMG, PKG, ISO, or ZIP files, some of them also signed with a valid Apple developer ID to make them look legitimate.

Shlayer samples found by TAU also use malicious shell scripts to download additional payloads just like older installments did...
 


I always figured this was inevitable but the process has started - received this from Apple this morning:
In an effort to keep your account more secure, two-factor authentication will be required to sign in to your Apple Developer account and Certificates, Identifiers & Profiles starting February 27, 2019.
I'm sure it's only a matter of time before 2FA is required on all accounts. What a PIA - I hate 2FA.
It is very important that developers have very secure accounts. We have had instances where miscreants have obtained developer credentials that enabled them to create versions of the apps that included malware. I prefer to be protected from developers' lack of security.

I do wish Apple handled its accounts better. This should be easier. But I find Apple 2FA easier than using Google Authenticator.
 



Apple ID and 2FA management is baked into iOS since 10.3 and is literally the first item in the Settings.
Can someone point me to a clear explanation of how 2FA works and how to set it up on an iPhone and a Mac? I've resisted doing this, as it has never made sense to me.
 


Apple is about to force me, as a developer, into 2FA for my developer Apple ID. Ironically, this will make it impossible for me to develop under certain circumstances. I often travel abroad to places where there is no roaming from my cellphone account; therefore it is impossible to call or text me through my cellphone number. But those are the only ways 2FA works! Therefore I won't be able to receive the access code, so I won't be able to access my developer account (which means I won't be able to build for a device, download Xcode updates, etc. etc.).

I already had this problem with my bank, when I needed to send myself money while abroad and couldn't because they insisted on doing 2FA.

This whole 2FA thing is very poorly thought through. It just assumes you always have your same cellphone number and that that number is always reachable, which in the real world is just not true.
 


...iit is impossible to call or text me through my cellphone number. But those are the only ways 2FA works! Therefore I won't be able to receive the access code, ....
I'm confused. I thought 2FA worked through any "trusted devices" and, according to https://support.apple.com/en-us/HT204915, a trusted device
is an iPhone, iPad, or iPod touch with iOS 9 and later, or a Mac with OS X El Capitan and later that you've already signed in to using two-factor authentication. It’s a device we know is yours and that can be used to verify your identity by displaying a verification code from Apple when you sign in on a different device or browser.
For me, 2FA always pops up an alert on my Mac (and my iPhone, and my iPad....) and I do not need to use text messaging.
 


This whole 2FA thing is very poorly thought through. It just assumes you always have your same cellphone number and that that number is always reachable, which in the real world is just not true.
As the Whos taught Horton, who then taught his/our world: A person's a person, no matter how small.

In the impossible-to-trust-anyone world we've built (wrecked) for ourselves, a person's a person only if they can prove they are, no matter how many more, and more, forms of authenticated identification they have personally, voluntarily (or otherwise) tacked to their person.
 


I often travel abroad to places where there is no roaming from my cellphone account; therefore it is impossible to call or text me through my cellphone number. But those are the only ways 2FA works!
Text message isn't the only way to do 2FA (in fact, it's probably the most insecure way to do it!).

Authentication apps that produce time-limited codes are another way to do 2FA, which doesn't necessarily require an active connection (depending on the means for verification).
 


Apple is about to force me, as a developer, into 2FA for my developer Apple ID. Ironically, this will make it impossible for me to develop under certain circumstances. I often travel abroad to places where there is no roaming from my cellphone account; therefore it is impossible to call or text me through my cellphone number. But those are the only ways 2FA works!
Isn't this scenario for which iOS Settings -> iCloud -> Password & Security -> Get Verification Code is designed (similar procedure in macOS; System Preferences -> iCloud -> Account Details -> Security tab -> Get Verification Code)? Maybe I am not understanding the situation you are describing.
 



This article was very interesting if you need to have 2FA on multiple iCloud accounts. There is a way to enable multiple iCloud accounts on the same device (who knew?)
Scripting OS X said:
Apple Two-Factor Authentication for a Secondary Apple ID
Apple sent an email to developers, stating that later this months, two-factor authentication will be required for Apple IDs used for developer accounts.

If you, like me, use separate Apple IDs for your personal iCloud and your developer accounts, this will pose some kind of challenge. There is a solution, however Apple does not document it very well.
 



Ric Ford

MacInTouch
Apple is about to force me, as a developer, into 2FA for my developer Apple ID. Ironically, this will make it impossible for me to develop under certain circumstances. ... This whole 2FA thing is very poorly thought through....
Here's a related article with some more details:
Bleeping Computer LLC said:
Apple Requiring 2-Factor Authentication on Developer Account Holders
... It turns out that the email is a bit confusing, as developer Christopher Pickslay contacted Apple Developer Relations and was told that only the Account Holder has to enable 2FA. Those who are in the admin role can still manage certificates and profiles without enabling this security feature.

Some developers have concerns with enabling 2-factor authentication, as according to the Two-factor authentication for Apple ID support page, once enabled it can up to two weeks to disable it again.

Users have become so frustrated with Apple's 2FA policy, that one Apple owner has gone as far as to sue Apple for forcing 2FA on his accounts.
 


Apple is about to force me, as a developer, into 2FA for my developer Apple ID. Ironically, this will make it impossible for me to develop under certain circumstances. I often travel abroad to places where there is no roaming from my cellphone account; therefore it is impossible to call or text me through my cellphone number. But those are the only ways 2FA works!
Actually, it's not. Use of a text message or phone number is Apple's "last resort" mechanism, for when you don't have a trusted device on-hand at the time.

Under normal circumstances, the 2FA code is generated locally by your trusted device. It pops up in response to a packet from Apple's server (delivered via an IP connection, whether over Ethernet, Wi-Fi or mobile data), but you can also manually tell your device to generate a code.

On a Mac (at least mine, running El Capitan):​
System Preferences -> iCloud -> Account Details -> Security (you may have to enter you password here) -> Get Verification Code​
On iOS (at least my iPhone 6+ running iOS 12.1.4):​
Settings -> (Your ID - the top link on the list) -> Password & Security -> Get Verification Code​
By the way, Google also doesn't require a phone number. You can set up your account to use the Google Authenticator app, which dynamically generates passcodes every 30 seconds or so (letting you select text message as a fallback). Google also lets you pre-generate a set of 10 "emergency" codes, which you can print and carry with you

It's also worth noting that there are even more 2FA options supported by some services, such as use of a code-generating key fob (e.g. SecureID hard tokens) and security-enabling USB dongles (e.g. YubiKey), although these often require you to purchase the key/device from the service provider.

I recognize that there are some 2FA mechanisms that do require phone/text access, but there are many (including Apple and Google) that do not.

It's also worth noting that using SMS/text messages for 2FA is not all that secure, thanks to hackers who conduct SIM-swapping attacks, where they trick your phone service provider to switch your phone number to their device and can therefore receive all your texts.
 


This whole 2FA thing is very poorly thought through. It just assumes you always have your same cellphone number and that that number is always reachable, which in the real world is just not true.
Yes! I very strongly agree with Matt.

I travel between Arizona and Thailand, and in each country I have a cell phone number, which of course is not the same!

This alone has stopped me from setting up 2FA, and when the day comes that I must do so, I believe that I will be in a world of hurt.
 


Yes! I very strongly agree with Matt.
I travel between Arizona and Thailand, and in each country I have a cell phone number, which of course is not the same! This alone has stopped me from setting up 2FA, and when the day comes that I must do so, I believe that I will be in a world of hurt.
There are other (non-Apple) Catch-22s, too: I don't know if this is still an issue, but three years ago, I arranged with Verizon for (reasonable, if not cheap) voice and data access with my iPhone 6 while on a short trip to France. I couldn't connect to anything, it turned out... because Verizon expected me to authenticate, but I had no device that could connect to the Internet or a voice network (at reasonable rates) to carry out their version of 2FA.

I finally had to call Customer Service (a number Verizon appears to do its best to conceal from its customers) using roaming (cough). Might have been easier just to buy a SIM with a specified number of talk minutes/data volume.
 


Regarding multifactor authentication, “Before You Turn On Two-Factor Authentication…” by Stuart Schechter at Medium was a decent read.
Stuart Schechter on Medium said:
…in trying to persuade users to adopt second factors, advocates sometimes forget to disclose that all security measures have trade-offs . As second factors reduce the risk of some attacks, they also introduce new risks. One risk is that you could be locked out of your account when you lose your second factor, which may be when you need it the most. Another is that if you expect second factors to protect you from those attacks that they can not prevent, you may become more vulnerable to the those attacks. …
 


I'm confused. I thought 2FA worked through any "trusted devices" and, according to https://support.apple.com/en-us/HT204915, a trusted device For me, 2FA always pops up an alert on my Mac (and my iPhone, and my iPad....) and I do not need to use text messaging.
I don't think 2FA will work if you are outside of the US and use a local SIM card in order to get less expensive data on your phone, because your phone number will not be the one registered for 2FA. (Maybe I'm missing something.)
 


Amazon disclaimer:
As an Amazon Associate I earn from qualifying purchases.

Latest posts