Archive for March 15, 2021

Monday, March 15, 2021

SMS Rerouting Vulnerability

Joseph Cox (tweet):

I hadn’t been SIM swapped, where hackers trick or bribe telecom employees to port a target’s phone number to their own SIM card. Instead, the hacker used a service by a company called Sakari, which helps businesses do SMS marketing and mass messaging, to reroute my messages to him. This overlooked attack vector shows not only how unregulated commercial SMS tools are but also how there are gaping holes in our telecommunications infrastructure, with a hacker sometimes just having to pinky swear they have the consent of the target.


While adding a number, Sakari provides the Letter of Authorization for the user to sign. Sakari’s LOA says that the user should not conduct any unlawful, harassing, or inappropriate behaviour with the text messaging service and phone number.

But as Lucky225 showed, a user can just sign up with someone else’s number and receive their text messages instead.


As for how Sakari has this capability to transfer phone numbers, Nohl from Security Research Labs said “there is no standardized global protocol for forwarding text messages to third parties, so these attacks would rely on individual agreements with telcos or SMS hubs.”


Horsman added that, effective immediately, Sakari has added a security feature where a number will receive an automated call that requires the user to send a security code back to the company, to confirm they do have consent to transfer that number.


Update (2021-03-19): Bruce Schneier:

Don’t focus too much on the particular company in this article.

Update (2021-05-24): Juli Clover:

Major carriers in the U.S. like Verizon, T-Mobile, and AT&T have made a change to how SMS messages are routed to put a stop to a security vulnerability that allowed hackers to reroute texts, reports Motherboard.

Mac Software Updates Open Up sshd

Rachel Kroll (Hacker News):

A couple of weeks ago, I read a post about how the “sealed system” on Big Sur was hurting people. I kind of skimmed through it and figured it was mostly complaining about the size of the download. For whatever reason, that hadn’t been a problem for me and my machines, so I kind of wrote it off.

Last night, I applied the latest security patches to arrive at Big Sur version 11.2.3, and realized that I should have paid more attention to that thing. It explained something that I had been noticing for a while: my Apache config would keep reverting.


Why would it matter if the sshd config got reverted? Simple: it’s because the stock Mac sshd install includes password-based auth, and that means someone can brute-force their way onto your machine if they can connect to it on port 22 for long enough.

I don’t understand how this would be caused by the SSV, and there’s a report that it’s actually been happening since Catalina. Big Sur updates are also removing the command-line developer tools, although this is also not due to the SSV, as far as I know.


Update (2021-03-16): TJ Luoma:

This has been happening for a long time, and not just on Big Sur. Apple resets 1) sshd_config, 2) ssh_config, 3) the config file that speeds up Time Machine, and 4) the setting that allows you to use Touch ID for sudo auth.

I now have scripts to re-apply those settings.

Also, after every point-update, macOS asks me if I want to turn on Siri (a setting I’ve never enabled on any Mac, ever…take a hint, Apple).

I recently turned off Document & Desktop sync via iCloud, and after a point-update, I was asked if I wanted to re-enable that too.


Update (2023-10-25): Rachel Kroll:

They’ve changed the way the config works [in Monterey] to add a “.d” directory scheme which sets some defaults. There is now /etc/ssh/sshd_config.d, and in it, 100-macos.conf.

Editing that file would likely get reverted upon the next patch (12.0.2?), so that’s right out. You can’t go past it with a higher number, since as the sshd_config points out, the first instance of a setting is kept, and subsequent instances of the same setting are ignored.

Instead, you have to get in front of them, and use a LOWER number. Try something like “000-yourname.conf”[…]

Larger and Slower Updates With Big Sur

Howard Oakley:

The first gigabyte or so of the update has to be downloaded direct from Apple’s servers[…] For M1 Macs these are marked out so that they can’t be obtained from the Content Caching Server. The size of this additional directly downloaded part of the update is essentially the same as the difference in total size of macOS updates between Intel and M1 Macs, around 1 GB.

Howard Oakley (tweet, Hacker News):

In macOS past, those two patches could have been small, whether installed by the system or using a downloadable Installer package. Several factors now conspire to turn a few kilobytes of changes into several gigabytes of update:

  • Firmware updates are only provided as part of a macOS update, and Apple deems it necessary for every macOS update to include a complete set of current firmware for Intel models. […]
  • The dyld cache, nine files occupying about 4 GB when compressed in /System/Library/dyld, which contains a dynamic linker cache of all the system-provided libraries. These fall within the SSV, and appear to have to be freshly provided in every macOS update.


As Jeff Johnson has reminded us, Apple still claims that Big Sur has “Faster updates. […]” Anyone who has been keeping Big Sur up to date over this last month knows that’s simply not true, and its reasoning is flawed.


Had Apple explained these costs and penalties of the SSV at last year’s WWDC, wouldn’t it have been booed from the virtual stage?

Howard Oakley:

With its change in version numbering system, macOS 11 has hopefully replaced the Supplemental Update with patch releases like 11.2.2. Although we haven’t yet reached 11.3, there have already been 6 updates to the initial 11.0 release, and there are marked differences between Intel and M1 Macs. The initial release for Intel Macs was 11.0.1, which was an update for early M1 models, which came with 11.0 pre-installed, and required immediate updating to 11.0.1. Sizes of updates are also different: for Intel Macs these have ranged from 2.3-3.27 GB, for M1s 3.1-4.2 GB. Total update size delivered so far has been 13.86 GB in 5 updates for Intel Macs, and 22.27 GB in 6 updates for M1 models.


Amazon Basics Copies Peak Design

John Gruber:

Amazon even called their rip-off the same name — “Everyday Sling” — although they’ve since changed the name to “Camera Bag”. The crew at Peak Design did the right thing in response: they mercilessly mocked Amazon in this video.


Parler Denied Re-entry to the App Store

William Turton and Mark Gurman:

When it initially removed Parler from the App Store in January, Apple asked the social network to change its moderation practices. Apple said that Parler’s new community guidelines, released when the service came back online Feb. 15, were insufficient to comply with the App Store rules.


“In fact, simple searches reveal highly objectionable content, including easily identified offensive uses of derogatory terms regarding race, religion and sexual orientation, as well as Nazi symbols,” Apple wrote “For these reasons your app cannot be returned to the App Store for distribution until it complies with the guidelines.”

The guidelines simply say:

1.2 User Generated Content

Apps with user-generated content present particular challenges, ranging from intellectual property infringement to anonymous bullying. To prevent abuse, apps with user-generated content or social networking services must include:

  • A method for filtering objectionable material from being posted to the app
  • A mechanism to report offensive content and timely responses to concerns
  • The ability to block abusive users from the service
  • Published contact information so users can easily reach you

Parler has all this. You can argue with how well it works, but the guidelines don’t state any specific requirements about that. They also don’t define “objectionable content,” except in the previous Section 1.1, which does not seem to be about user-generated content and is obviously not applied to other social apps.

Mike Rockwell:

Maybe you dislike Parler. And given the content on the platform, maybe there’s plenty of reasons to. But I can’t help but wonder if requiring more robust moderation systems from platform makers is in some ways bolstering the status quo.

Are these App Store policies making it even more difficult for a smaller service to actually compete with the likes of Facebook, Twitter, Reddit, and YouTube? Could a scrappy startup with limited resources actually buildup a compliant moderation system quick enough if they suddenly get an influx of new users?

The answer is that it depends on whether Apple likes you. If you go by Apple’s written guidelines, multiple apps were compliant, yet rejected anyway. If you go by Apple’s stated objections, none of the major apps are compliant, yet they’re in the store, anyway.


Update (2021-03-16): Mike Rockwell:

Regardless of your opinion about Parler, it’s clear that Apple’s policies are not enforced uniformly. And yes, I agree with the likely rebuttal — the App Store is a private platform, Apple makes the rules and can remove an app for any reason. But there’s a difference between what they can do and what they should do. Without any predictability to policy enforcement, developers are left in the dark. And the smaller developers are the ones hurt the most.


But I would also advocate for opening the platform. Because no matter how hard Apple tries, the review process will never be perfect. Just let developers distribute their own apps.