Perpetual IT

Buh-bye, original way of tweeting: Twitter said that for the most part, it’s turned off its Twitter via texting service.

Besides a few countries that rely on the feature, Twitter’s turned off its ability to take in our SMS messages and turn them into tweets. On Monday, it said on its support account that it’s killed SMS tweeting in order to keep our accounts safe, referring to SMS-enabled vulnerabilities for which it didn’t give any details.

We want to continue to help keep your account safe. We’ve seen vulnerabilities with SMS, so we’ve turned off our Twitter via SMS service, except for a few countries.

Everyone will still have access to important SMS messages needed to log in to and manage their accounts.

This isn’t a biggie for most of us, given that nowadays, the vast majority of Twitter’s users access the service via its mobile or online apps. And, as Twitter noted, you can still use SMS messages to do important things, like sending authentication codes needed to log in.

But “most of us” isn’t all of us.

One business, DansDeals, said in a post on Saturday that it’s been sending SMS alerts about new deals to its customers for more than 11 years. With Twitter’s abrupt move, it saw its follower count fall from 97,000 to below 89,000.

Over the weekend, Twitter apparently started sweeping out followers who signed up for DansDeals SMS alerts via the platform’s Fast Follow SMS service – a service that doesn’t require US users to have a Twitter account in order to receive tweets. Twitter rolled out Fast Follow nearly a decade ago.

Here’s part of Twitter’s (now-not-so-much) lauding of SMS messaging when it announced Fast Follow:

We’ve always been big fans of trusty SMS messaging. In fact, sending a text was originally the only way users could tweet. This is why Tweets are 140 characters — they need to fit into a text message.

Well, things change. This isn’t the first time that Twitter has seriously reconsidered its appreciation of “trusty” SMS messaging.

In August 2019, Jack Dorsey’s Twitter account got hijacked. A week later, Twitter temporarily yanked the ability to tweet via SMS – one of the possible ways that the account of its founder and CEO got taken over by racist/anti-semitic/bomb-hoaxing hijackers .

At the time, Twitter said that it was doing so due to vulnerabilities that mobile carriers need to address, and due to its reliance on having a linked phone number for two-factor authentication (2FA) – something it said that it was working to improve.

Besides security issues, killing off SMS-based texting is good for Twitter’s bottom line: namely, Twitter can’t show ads to people who tweet via SMS like it can within its online or mobile apps.

---

Latest Naked Security podcast

It’s happened again!

A weird combination of Unicode characters that make up a nonsense word can crash your iPhone, apparently by confusing the iOS operating system when it tries to figure out how to display the “word”.

(We say apparently because we have an iPhone 6+, which is stuck back on iOS 12, and we couldn’t get our phone to crash, although we’ve seen one person on Twitter claiming that their iOS 12 device was affected.)

If you’re a regular Naked Security reader, you’ll have a feeling not just of having read this before but of having read it before before, because we covered similar troubles for iOS back in 2013 and in 2018.

And it’s not only Apple that has been in the firing line here, with the WhatsApp software having similar issues in the past dealing with legal-but-unusual character code combinations, and leading to what was described at the time as a “text bomb“.

The good news is that although all these flaws can cause serious annoyance and make your phone unresponsive, possibly requiring a hard reboot…

…there’s no permanent damage, no malware installed, no data stolen and no other nasty cybsersecurity side-effects to go with it.

But it does sound like a pretty annoying problem.

Back in 2013, Apple’s “text to crash them all” relied on unusually laid out writing in Arabic; the 2018 Apple bug was caused by the complicated character-combining rules of the Telugu language; and WhatsApp’s 2018 problem was a long sequence of special codes that told the software to switch over and over again between writing left-to-right and writing right-to-left.

This time, as far as we can tell, it’s Arabic characters that have again been used to provoke the processing bug that causes iPhones to get bogged down.

We don’t know how to read Arabic writing, or indeed the text of any Semitic language, but we do know that the writing systems of these languages generally differ from most European languages.

For example, Semitic languages are usually written from right-to-left, and they often don’t bother writing vowels, assuming that the reader can supply the missing sounds from experience, in much the same way that we know instinctively what is meant when we see English pseudo-words such as RSPCT, XCLLNT and NKD SCRTY.

Of course, there are some words that even a well-read student of Arabic might not be sure how to say aloud, such as the names of foreign people and places, or phrases for which correct pronuniciation is considered important, such as names and words of religious significance, or words that are confusingly ambiguous without some extra help.

The orthographic answer is to provide so-called diacritical marks to denote missing vowels where needed. (The equivalent in European languages are symbols such as accents, cedillas and other top-or-bottom squiggles that clarify punctuation or adjust the sound of a syllable.)

However, the way diacritics are encoded into the Unicode character set differs greatly between languages such as French or English, and languages such as Hebrew and Arabic.

French, for example, has a separate character encoding for each of, say, E, E-with-an-acute-accent, A, A-grave, and so on.

But if the French language allowed every character from A to Z to take any or all accents in varying mixtures, there would be far too many possible combinations to list them all as unique code points in the Unicode set.

Indeed, that’s the problem you would have if you tried to create a distinct character code for every possible combination of letter-and-diacritic in every possible layout in a language such as Arabic, so the answer is to use so-called “combining characters” instead.

Unfortunately, that can lead to algorithmic complications for computerised text-management, because the computer can’t just set one character at a time and move onto the next.

The next character, or the one after that, or the one after that when taken into account with the one before it (or some other complex permutation), might affect how the current character, or glyph, is to be constructed and displayed.

As far as we can tell, then, the dubious “word” in the current iPhone “message-of-death – shown recently on Twitter in a video by popular Apple fan EverthingApplePro – is constructed by taking a simple word that no-one would have trouble with…

The craziest iOS crash text bug 💀 pic.twitter.com/29LJPb67WP

— EverythingApplePro (@EveryApplePro) April 23, 2020

…and jamming it full of repeated, redundant and contradictory vowel markings that can’t usefully be turned into a real word at all.

(If someone said to you, “Please write the word BAD,” and then demanded you to spell it with three Es, two Us, a few Is and five carets squeezed in tightly somehow between the A and the D, you wouldn’t spend hours trying to find a layout that could fit all the little characters in given that the outcome would be a kind of illegible nonsense anyway – you’d assume the instructions were garbage and ignore them.)

Bad made worse

In fact, if Google Translate is to be believed, the “word” that we have seen offered online to provoke this crash, when shorn of its confusing and contradictory vowel and syllable diacritics and written normally, is apparently the Urdu word for bad, roughly pronounced bara.

As close as we can get in English, the crash-me version of the word is confusingly padded out to be something more like this:

B[nnnnaauuibbbbbbb*]R[nnnnaauuiirrrrrrr*]A[nnnauaa]

(The diacritic denoted above as * is SUKUN, used to clarify that there isn’t actually a vowel sound at all, despite numerous and repetitious vowel markers having preceded it in this case.)

So, in making sense of a ludicrously bad encoding of the word bad, it seems that Apple apps that try to print it on screen get locked up in a processing loop that eventually makes the phone dysfunctional for a while.

Simply put, it’s a low-level Denial of Service (DoS) problem.

What to do?

According to EverythingApplePro on Twitter, you can stand down from red alert if someone who thinks they’re being funny sends you a message notification with this “word of death” in it.

Eventually, the app trying to process the character will crash and you can start again (though deleting the message before it shows up again might be a challenge).

Or you can simply do a hard reboot of your iPhone and get control back by turning it off and back on.

To force a shutdown, hold one of the volume keys and then press the wake/sleep button on the right for a few seconds (or just hold the wake/sleep button on older devices) until the power off slider pops up on the screen.

Apparently, the next release of iOS, currently at iOS 13.4.5 Beta and due soon, has a fix for this bug so you won’t have to worry about it for too long.

In the meantime, as tempting as it might be and as “mostly harmless” as it might feel, don’t send messages of this sort to your friends as a misguided attempt at a joke.

We suspect there may be many other similar Unicode character combinations that might trigger this text-munging flaw, so we suggest you simply assume that rather than trying to find out new ones that online messaging services won’t yet know how to [REDACT] for safety.

In short, enjoy this story, but don’t use it as a reason to go bad yourself.

---

Latest Naked Security podcast

Germany on Sunday pulled an about-face regarding the best way to use smart phones to trace people’s contacts with those infected by COVID-19, embracing a decentralized Bluetooth-based approach instead of the more invasive location tracking proposed in other approaches.

The Bluetooth approach – which keeps data local on people’s phones instead of being stored on a centralized database that could be used for mass state surveillance or to track people – is supported by Apple, Google and other European countries, Reuters reported.

Apple and Google first announced their contact tracing collaboration two weeks ago, on 10 April. Instead of “contact tracing,” though, they’re calling it an Exposure Notification system.

As the companies have explained in an FAQ about their approach, it will come in two phases, both of which will use Bluetooth technology on mobile devices to aid in contact tracing efforts.

The first phase will be an API that works across iOS and Android devices for public health agencies to integrate into their own apps. That’s due in May. The second phase, due in coming months, will be introduced at devices’ operating system levels to ensure broad adoption – a key element in the success of contact tracing.

It will be done on a strictly opt-in basis. After the operating system updates and a user has opted in, the Exposure Notification system will start pinging the Bluetooth beacons of nearby devices. Preliminarily, users won’t have to install an app to get those notifications. But if a match is detected that shows a user has come into contact with somebody who’s infected, the user will be notified.

If they haven’t already downloaded the official app, they’ll be prompted to do so and will be advised on what to do next, such as take steps to get tested or self-quarantine. “Only public health authorities will have access to this technology and their apps must meet specific criteria around privacy, security, and data control,” according to the FAQ.

If a user tests positive for COVID-19, they’ll be able to work with their health authority to report the diagnosis within the app. Then, with their consent, their beacons will be added to the list of devices belonging to people who’ve tested positive. Users’ identities won’t be shared with other users, with Google or with Apple.

CNET has done a deep dive on the measures that Google and Apple are taking to protect people’s privacy with this approach. for its part, Google provided this video and graphic to explain the basics of the system:

[embedded content]

As Google and Apple tell it, the system – which will run on either Apple’s iOS or Google’s Android operating systems – requires explicit user consent. It collects neither users’ personally identifiable information (PII) nor their location data.

The list of people you’ve been in contact with never leaves your phone.

The system relies on smart phone beaconing: the use of a phone’s built-in radios and Bluetooth to constantly ping other devices with a long, unique string that identifies a device: what the companies say is a string of random numbers that aren’t tied to a user’s identity and which change every 10-20 minutes to protect users from being tracked. Servers relay a device’s last 14 days of IDs to other devices that then look for a match, searching for devices that came within six feet of each other for a given amount of time.

If the app detects that a user has come into contact with somebody who’s tested positive for COVID-19, the system will tell them what day it happened, how long the contact lasted, and the Bluetooth signal strength of that contact. That’s the full extent of the information that will be shared about the contact.

On Friday, Apple and Google said in a press briefing that besides relying on Bluetooth instead of location data, and on top of regularly changing the identifying IDs, they’ve also added a new layer of encryption for the tracing data. The extra encryption layer will make it tougher to identify those who’ve tested positive for COVID-19 and will also encrypt data to make it harder to use as a digital fingerprint if it’s exposed.

“Nein” to centralized data storage

As Reuters tells it, as late as Friday, Germany was backing a different approach to contact tracing called Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT). That approach relies on tracking contacts by monitoring the proximity of their phones.

In fact, Germany was leading that initiative, which had the support of seven European countries as of last week.

That support went on to melt after 300 scientists published an open letter expressing concerns about PEPP-PT last Monday (20 April). They argued that PEPP-PT lacks transparency and that its centralized storage of data might be exploited by governments for discriminatory practices or invasive state surveillance.

We are concerned that some ‘solutions’ to the crisis may, via mission creep, result in systems which would allow unprecedented surveillance of society at large.

The scientists came out in support of an alternative standard, called DP-3T, that they claimed is more privacy-preserving. At least three of the European countries that initially supported a contact-tracing app that relies on location data and centralized data storage had switched to supporting DP-3T as of Friday.

On Friday, German Chancellery Minister Helge Braun and Health Minister Jens Spahn said in a joint statement that the country would dump its own, home-grown approach to contract tracing, which would have given health authorities central control over the tracing data.

A senior government source told Reuters that it was Apple’s refusal to tweak settings on its iPhones – a change that would have been required to adopt PEPP-PT – that forced Germany to change course.

In a joint statement, Braun and Spahn said Germany would now adopt a “strongly decentralized” approach:

This app should be voluntary, meet data protection standards and guarantee a high level of IT security. The main epidemiological goal is to recognize and break chains of infection as soon as possible.

Apple and Google plan to collaborate with other initiatives, like the Swiss-led DP-3T, that similarly use a decentralized system that stores data on individual devices instead of in a centralized database.

---

Latest Naked Security podcast

Microsoft has quickly fixed a flaw in its Teams videoconferencing and collaboration program that could have allowed attackers to launch a wormlike attack on multiple accounts by sending one victim a malicious GIF image.

Discovered by Israeli security company CyberArk, the underlying weakness is a combination of two issues.

The first concerns the way Teams manages authentication tokens.

Teams can generate a lot of these, depending on what it is accessing (SharePoint, Outlook, for example), which gives the user the right to view content or resources from a Microsoft subdomain accessed during a session.

To simplify, the ability to view an image is defined by two tokens, skypetoken_asm and authtoken, that also control lots of requests a user can make through the Teams API and Skype, such as sending and reading messages, creating groups, adding users and changing permissions.

Importantly, if an attacker could somehow get hold of an authtoken they could generate their own skypetoken. That should be impossible because such tokens are only sent to Microsoft subdomains… which is where the second weakness becomes important.

Unfortunately, CyberArk discovered two Microsoft teams.microsoft.com subdomains that proved vulnerable to takeover, which immediately created the architecture for an attack:

If an attacker can somehow force a user to visit the sub-domains that have been taken over, the victim’s browser will send this cookie to the attacker’s server and the attacker (after receiving the authtoken) can create a skype token.

The only caveat to that is the attacker would still need to get hold of a valid certificate for a targeted subdomain, which CyberArk believes wouldn’t prove a big hurdle.

But why use a malicious GIF?

Because it would be much harder to defend against than the old trick of sending victims a malicious link. To prove the point, CyberArk worked out that it would be possible to send a targeted user a message which would retrieve a a specially-crafted malicious proof-of-concept Donald Duck Evil.GIF image from a hijacked subdomain.

Simply displaying this would execute the theft of the user’s authtoken, thereby giving the attacker access to their chats, control of the account, and the ability to forward the same message to anyone in their group. Without quick intervention, this could have allowed an attack to compromise large number of big company accounts and groups.

Who is vulnerable?

Anyone who accesses Teams using the Teams application or via a web browser. In theory, internal Teams groups wouldn’t be affected although an attack could still be launched if external communication (such as videoconferencing) was possible.

Is there a fix?

Microsoft was told about the issue on 23 March, after which it corrected the misconfigured DNS subdomains. On 20 April, the company has pushed out other tweaks to close the vulnerability so the issue should be fixed by now providing updates have been applied, which should happen automatically.

There are no indications the flaw has been exploited by a real attacker.

---

Latest Naked Security podcast

If you’re a system administrator, the network you look after is almost certainly way more spread out since coronavirus stay-at-home regulations kicked in.

But even if your colleagues are using their own computers now, and connecting in via their own internet connections, it’s still “your” network, and it still represents a valuable target – as a network, not just as numerous individual computers – to cybercriminals.

And one of the most dramatic all-at-once attacks that your network can suffer is, of course, ransomware.

Ransomware attacks often rely on victims making a few basic mistakes that are often quite uncomfortable to confront – it’s natural to assume you haven’t made any (or, at least, not many), and it can feel both tired and tiring to keep going through the basics.

So we decided that we’d find a fun way to help you to keep track of the common blunders that often lead to ransomware – something with rhyme and rhythym as well as reason.

Imagine that your computer were a house, and ransomware a gang of burglars, and chant along with us…

 Don't lock the door and then forget And leave the windows wide. <--PROTECT YOUR SYSTEM PORTALS Don't think that keys beneath the mat Will keep the crooks outside. <--PICK PROPER PASSWORDS Don't set a guard to watch all night And write things in a book, Yet when you get their careful notes, just never take a look. <--PERUSE YOUR SYSTEM LOGS Don't buy alarms but turn them off Because they make a row. <--PAY ATTENTION TO WARNINGS And when you need to do repairs, Don't shrug, and say, "Not now." <--PATCH EARLY, PATCH OFTEN

We’ve summarised the actions you can take into 5 simple phrases, each starting with P so they’re easy to remember.

1. Protect your system portals

Crooks often sneak in by looking for remote access portals such as RDP (remote desktop protocol) and SSH (secure shell) that aren’t properly secured, perhaps because they were set up temporarily but then forgotten about.

Learn how to scan your own network from the outside and make sure that any services that are open and listening for connections are supposed to be there, and that they are on your regular security checklist.

If you don’t check your network for access holes you’ve left open by mistake, then the crooks will do it for you!

2. Pick proper passwords

When you’re in a hurry, especially if you have to rely almost exclusively on remote access these days due to coronavirus lockdown, it’s easy to take shortcuts to “get it working” and to promise yourself you’ll check all the locks and latches later.

Yet every time there’s a huge password dump due to a data breach, you will invariably find the password changeme somewhere near the top of the list.

Clearly, lots of people start out with basic passwords with every good intention to pick a proper one soon, but then never get around to it.

Start as you plan to go on, with proper passwords from the outset, plus two-factor authentication to augment your security whenever it’s available.

3. Peruse your system logs

Many, if not most, ransomware attacks don’t happen instantly or without warning – the crooks usually take some time, often days and sometimes longer, to get a picture of your entire network first.

That’s how they make sure, when they finally pull the trigger that initiates the attacks, that they will get the destructive result they want for the ransom they plan to demand.

So there will often be numerous telltale signs in your logs, such as the appearance of “grey hat” hacking tools that you wouldn’t expect your own users to need or use; sysadmin operations such as creating new accounts that happened at unusual times; and network connections from outside that don’t follow your usual pattern.

(The Sophos Managed Threat Response team can help you here – they know not only what to look for but also where to find it.)

4. Pay attention to warnings

If you’ve set up your alerting system to shout at you all the time, you will almost certainly end up with alert fatigue, where you just click through because you’ve run out of time.

But be careful not to assume that otherwise interesting warnings can be ignored if they mention a potential threat was already blocked.

Often, threats that pop up on your network aren’t just chance events, they’re evidence that crooks are already poking around cautiously to see which actions set off what alarms, in the hope of pulling off a much bigger attack later on.

5. Patch early, patch often

Don’t leave yourself exposed to potential holes for longer than necessary.

While the crooks are scanning your network for ways to get in (see 1), they can also scan for externally accessible services that aren’t patched at the same time.

This helps the crooks automatically build lists of potential victims to come back to later – so your best result is simply not to be on their list!

---

Latest Naked Security podcast