This week we discuss the stalkerware app that spilled bucketloads of ultrapersonal data, a double-whammy ransomware attack on a homeless charity, and an Amazon Prime-themed phishing attack with a skull-and-crossbones twist.
Producer Alice Duckett hosts the show with Sophos experts Paul Ducklin, Greg Iddon and Peter Mackenzie.
Listen now!
LISTEN NOW
Click-and-drag on the soundwaves below to skip to any point in the podcast.
Users looking for a privacy-focused browser might want to consider Brave first, according to a study published this week.
Douglas Leith, professor of computer systems at Trinity University, examined six browsers for his report – Web Browser Privacy: What Do Browsers Say When They Phone Home? He found that Brave’s Chromium-based browser is the least likely to reveal unique identifying information about the computer using it.
The study examined six browsers: Chrome, Firefox, Safari, Brave, Edge, and Yandex. It used several tests to deduce whether the browser can track the user’s IP address over time, and whether it leaks details of web page visits. To do this, it looked at the data shared on startup after a fresh install, on a restart, and after both pasting and typing a URL into the address bar. It also explored what the browser did when it was idle.
Even though Mozilla makes a talking point of privacy in Firefox, it was Brave, developed by Mozilla’s founder (and creator of JavaScript) Brendan Eich, that won out. Brave, which has accused Google of privacy violations, is “by far the most private of the browsers studied” when used with its out of the box settings, according to the paper.
The study placed browsers in one of three privacy classes, based on the time span over which they retain identifiers. Brave gets the top class all to itself because it uses what the study calls ‘ephemeral’ identifiers that link a handful of transmissions and then reset. This means it doesn’t remember your identifier across browser restarts.
The paper lumps Safari, Firefox, and Chrome together in the second band. These browsers share some privacy issues, the paper warns, including auto-tagging each browser instance with unique session and browser instance identifiers that can persist across restarts. These behaviours can be disabled but they’re turned on silently by default, the paper claims.
The research picks out four identifiers that Firefox uses. Two created by the browser persist across browser restarts, while the third changes between browser sessions but could be linked together because old and new values are sent together in a telemetry message, the paper said. The fourth identifier, created by the server, is associated with an open web socket used for Firefox’s push services. Firefox also sends user IP addresses with these identifiers.
Leith’s paper acknowledges that Mozilla deletes the IP addresses sent with these identifiers after 30 days, but frets that the company is “silent on the uses to which the IP data is put.” He worries that this could be used to track the user’s location, adding:
That does not mean such linking actually takes place, only that the potential exists for it to be done.
Leith had asked Mozilla whether it used IP addresses for location tracking, and also asked for the company’s IP address usage policy as part of its push service. He received no response. Mozilla spokesperson Justin O’Kelly didn’t address those issues specifically with us, but responded:
Firefox does collect some technical data about how users interact with our product, but that does not include the user’s browsing history. This data is transmitted along with a unique randomly generated identifier. IP addresses are retained for a short period for security and fraud detection and then deleted. They are stripped from telemetry data and are not used to correlate user activity across browsing sessions.
Leith’s paper also calls out Safari, which it said allows all the third-party sites listed on its start page to set cookies without user consent. It also phones home to icloud.com even from machines that aren’t registered with that Apple service, the paper warns, calling this connection “spurious”.
Apple was also the most aggressive browser when it came to sending data that users typed into the address bar back to Apple servers for autocomplete purposes, the paper warned:
The requests to Apple include identifiers that persist across browser restarts and so can be used to link requests together and so reconstruct browsing history.
Apple didn’t respond to our request for comment.
Google’s Chrome phones home almost every letter typed into the search bar for autocomplete purposes, the paper said. Even after unticking the ‘allow telemetry’ box, the browser sets up a cookie with Google’s server that it then communicates each time the browser is opened, Leith found, and this happens even if the user isn’t logged into Google. Google declined to comment for our article but pointed us to its Chrome Privacy White Paper.
The issue for many of these browsers seems to be not so much what they’re doing, as the fact that they do it by default, leaving non-techie or unaware users open to more information gathering. From Leith’s paper:
In summary, Chrome, Firefox and Safari can all be configured to be much more private but this requires user knowledge (since intrusive settings are silently enabled) and active intervention to adjust settings.
The paper reserves the gravest concerns for the third, least private group that it identified, containing Edge and Yandex. These use identifiers linked to the device hardware, it said, persisting across fresh browser installs. They can also be used to link different apps running on the same device.
Edge also contacts a Microsoft advertising server, the paper said, which sends back several identifiers that Edge then echoes in subsequent requests to that server. It added:
Loading of the Edge welcome page sets a number of cookies. In particular, this includes a cookie for vortex.data.microsoft.com, which appears to be a data logging server, and allows data transmitted to this server to be linked to the same browser instance.
Even pasting (rather than typing) a URL into the address bar contains what the paper calls “unwanted consequences”, including leaking user browsing history to Bing via the search engine’s autocomplete API, and once again contacting vortext.data.microsoft.com.
Microsoft’s Edge privacy page says that it sends device identifiers as part of a diagnostics reporting service that users can turn off. Users can also delete this data on the server. According to its Edge privacy white paper, people can turn off Search Suggestions to stop it sending your search terms to Bing, which otherwise keeps them for six months.
Yandex didn’t respond to the paper’s allegations that its browser, popular among Russian speakers, sends user browsing data to Yandex servers as part of its autocomplete API, along with the text of web pages to its translation service. It also sends the SHA-1 hashed MAC address of a machine to Yandex, along with browser identifiers, enabling them to be tied together, Leith’s paper said.
LISTEN NOW
Click-and-drag on the soundwaves below to skip to any point in the podcast.
Evidence is emerging that a barely noticed change made to Chrome 80, released on 4 February, might have disrupted the hugely successful data and user profile stealing malware AZORult.
AZORult first appeared in 2016, since then it has been used to thieve huge amounts of information from victims, including everything from cryptocurrency data, passwords, web browsing history and cookies, to credentials for FTP clients, desktop Telegram, and Skype chats.
You name it, AZORult will try to steal it, often posing as legitimate software such as the installer for ProtonVPN.
The malware went into a relative decline in 2018. And now, according to research by Israeli security company Kela, chatter on crime forums suggests cybercriminals believe that Chrome 80’s move to encrypt locally saved passwords and cookies using AES-256 has killed the malware’s attempts to steal data for good.
When running on Windows, Chrome previously relied on Microsoft’s systemwide Data Protection API (DPAPI), which has proved susceptible to popular credential cracking tools such as Mimikatz.
“All the older cracked versions of different stealers are finished,” Kela translates a Russian language commenter on a crime forum as having said.
Apparently, AZORult’s problem is that in the wake of growing fragmentation, its development seems to have stalled. Other data stealers such as Racoon and Kpot are said to have evolved to cope with the change, although how successfully is not explained.
The evidence for AZORult’s demise is supported by Kela’s figures showing that the Genesis crime market where user profiles and credentials are traded has seen a sudden and dramatic drop in those connected to AZORult.
Genesis is viewed by some security companies as one of the most innovative crime marketplaces because it trades mostly in user ‘fingerprints’ that criminals can use to emulate or spoof victims. This includes unique aspects of their browsing behavior, IP address, software installation and computer hardware.
Until now, the go-to for that has been AZORult. In an interview with ZDNet, Kela’s Raveed Laeb said that the Genesis database of stolen credentials had gone down from 335,000 to around 230,000 in a matter of weeks.
While the marketplace is unlikely to disappear, Chrome’s evolution is likely to spell the death knell for AZORult, at least:
With no apparent heir to fix the deep issues caused by the new Chrome update, it seems that actors – if we’re extrapolating from Genesis – have actually decided to move on to new stealers.
Chrome’s switch to AES-256 also affects other browsers based on Chromium, including Microsoft’s new Edge browser, Opera and Brave.
The only way for AZORult to adjust to this change would be to patch the original source code, but this is no longer available.
Nevertheless, the data stealing function of AZORult will be taken up by plenty of willing rivals. It’s a case of one down, plenty more to go.
Demonstrably not. Which is why the easiest way to dodge the issue of browser password manager weaknesses is not to use them at all, opting instead for a full-blown password manager.
Unlike browsers, these are extensions dedicated to the job of securing passwords. They offer more sophisticated security design, and will work across different platforms, browsers and computers. The additional security they offer over browser password stores is more than worth the minimal time spent setting them up.
LISTEN NOW
Click-and-drag on the soundwaves below to skip to any point in the podcast.
To most iOS users, pasteboard is simply part of the way to copy and paste data from one place to another.
You take a picture, fancy sharing it with friends, and your phone uses the pasteboard to move the image to the desired app.
Now an app developer called Mysk has discovered pasteboard’s dark side – malicious apps could exploit it to work out a user’s location even when that user has locked down app location sharing.
The weakness here is caused by the fact that, unless GPS permissions were refused, images taken with the embedded camera app on iPhones and iPads are saved with embedded GPS metadata recording where each was taken.
In the simplest scenario, an iPhone user would take a photo, copy it between apps using the pasteboard, from which a malicious app could extract location metadata while comparing it with timestamps to determine whether it was current or taken in the past.
Images taken from third-party web sources could be filtered out by comparing aspects of an image’s metadata with the device’s hardware and software properties to detect differences.
Although a malicious app should only be able to access pasteboard data while active, Mysk’s bypass was to write a demo app, KlipboardSpy, paired to a foreground widget visible in Today View, to prove the hack worked under real-world conditions. Moreover:
As the pasteboard is designed to store all types of data, the exploit is not only restricted to leaking location information. By gathering all these types of content, a malicious app can covertly build a rich profile for each user, and what it can do with this content is limitless.
That’s not only location data, then, but potentially anything the user has copied into pasteboard, including passwords and bank details.
There was a time when the ability to siphon GPS location history from smartphone images would have sounded of marginal use to a surveillance app. These days, however, image- and data-sharing has exploded, as any visit to social media will attest.
And yet when Mysk reported the issue to Apple, the response was muted:
We submitted this article and source code to Apple on January 2, 2020. After analyzing the submission, Apple informed us that they don’t see an issue with this vulnerability.
Arguably, Apple is correct because the pasteboard is working exactly as intended – it allows users to exchange data within and between applications while the latter are in the foreground.
That is, while it’s true that data can be slurped from the pasteboard in theory, that hypothetical downside is outweighed by the certainty that people need to access copy-and-paste on a daily basis.
Mysk’s view is that Apple could protect the iOS pasteboard by integrating it inside its permissions system, allowing users to grant access one app at a time, or by limiting the time apps can access it to the copy-and-paste action.
Currently, this is a theoretical weakness that, as far as anyone knows, has never been exploited. It’s likely that Apple will patch up this risk at some point as the permissions system inside iOS evolves.
LISTEN NOW
Click-and-drag on the soundwaves below to skip to any point in the podcast.
Researchers have found a way to impersonate mobile devices on 4G and 5G mobile networks, and are calling on operators and standards bodies to fix the flaw that caused it.
Research into the vulnerability, conducted by academics at Ruhr Universität Bochum and New York University Abu Dhabi, is called Impersonation Attacks in 4G Networks (IMP4GT), although deployment requirements for 5G networks mean that it could work on those newer systems too.
The attack targets LTE networks, exploiting a vulnerability in the way that they authenticate and communicate with mobile devices. The researchers claim that they can impersonate a mobile device, enabling them to register for services in someone else’s name. Not only could an attacker use this to get free services such as data passes in someone else’s name, but they could also impersonate someone else when carrying out illegal activities on the network, they point out:
The results of our work imply that providers can no longer rely on mutual authentication for billing, access control, and legal prosecution.
It wouldn’t necessarily let you into someone’s Gmail, because you might still have strong password protection or, more sensibly, be using MFA. Neither would it let you access someone’s SMS-based 2FA messages, David Rupprecht, one of the report’s authors, told us:
Under the assumption the authentication app is correctly implemented, e.g. uses TLS for the transmission, the attacker can not access that information. Text messages are part of the control plane and are therefore not attackable.
LTE networks use a mechanism called integrity protection, which mutually authenticates a device with the nearby cellular base station using digital keys. The problem is that this integrity protection only applies to control data, which is the data used to set up telephone communications. It doesn’t always apply to the user data, which is the actual content sent between the phone and the base station.
Rupprecht and his colleagues have already proven that they can use this weakness to change data sent between the phone and the base station, redirecting communication to another destination by DNS spoofing. This all happens at layer two of the network stack (the data link layer, which transports data across the physical radio link).
The IMP4GT attack takes this vulnerability a step further by using it to manipulate data at layer three of the LTE network. This is the network layer, handling things like user authentication, tracking devices around the network, and IP traffic.
Rather than just redirecting IP packets, the new attack accesses their payload and also injects arbitrary new packets, giving the researchers control over the mobile session. They do this by mounting a man-in-the-middle attack, impersonating the base station when dealing with the mobile device, and impersonating the mobile device when talking to the base station.
The vulnerability not only affects existing 4G networks but also has implications for the 5G systems that carriers are rolling out. Companies are implementing these systems in two phases, the researchers explain. The first uses dual connectivity, where the phone uses 4G for the control plane and the 5G network for user data. The user channel doesn’t use integrity protection in this case.
The second phase of the rollout, known as the standalone phase, sees 5G networks used for both control and user data. However, this implementation only mandates user data integrity protection on user channel connections up to 64kbit/sec, which is tiny by 5G standards. Integrity protection on user channels with higher speeds than that is optional. The researchers called for mandatory full-rate integrity protection.
Probably not! The attacker needs to be highly skilled and in close proximity to the victim. Besides the specialized hardware and a customized implementation of the LTE protocol stack, conducting the attack outside a controlled lab environment and without a shielding box would also require more engineering effort. However, for single targets of high interest it might be worth to meet the constraints above.
LISTEN NOW
Click-and-drag on the soundwaves below to skip to any point in the podcast.
