STE WILLIAMS

Cyber-wrath of Iran for top general’s assassination hasn’t progressed beyond snooping and nicking logins… yet

The Iranian cybercrime group that was expected to spearhead the rogue Middle East nation’s revenge for the US assassination of General Qasem Soleimani has quite the arsenal at its digital fingertips.

Infosec researchers from Secureworks said the state-sponsored phacker crew – dubbed Cobalt Ulster – has “destructive and disruptive cyber capabilities” at its disposal which it targets against Turkey, Jordan and Iraq.

Yet after Soleimani was killed in an American drone strike in January, the hackers kept quiet instead of unleashing a visible campaign of retribution.

The Iranian general, a member of the country’s Islamic Revolutionary Guard Corps, was credited by informed observers in the West with playing a key role in ensuring unstable regions of the Middle East acted largely in Iran’s interests. He did this through running a formidable network of intelligence operatives and militias.

Instead, said Secureworks, they just kept on going with their existing campaigns of spying and hoovering up login credentials through spearphishing attacks and the like.

The infosec biz’s Counter Threat Unit said of its findings: “In some cases, emails were sent with a malicious attachment to gain access, some email messages also contained a link to a compromised website, and there are confirmed cases where malicious documents were sent via a ZIP archive.”

They added: “From a threat management and risk assessment perspective, we advise organisations not to conflate ongoing espionage operations with a retaliatory response. However, continually leveraging threat intelligence to assess and improve controls will help network defenders secure their environments against malicious activity regardless of intent.”

In plain language, this means an uptick in nefarious activity on your network probably doesn’t mean you are on the front line of Iran’s revenge attacks against the West for bumping off their top espionage bloke. But never say never.

The attack methods mentioned by Secureworks in its blog post included some fairly standard phishing techniques, such as enabling macros embedded in Microsoft Office documents (a standard way of bypassing security controls). In turn that prompts the downloading of running of a PowerShell downloader that introduces whatever malware nasties the Iranians want to infect your networks with.

Usefully, at the end of its blog post Secureworks also published a list of URLs that it said had been associated with Iranian malware command-and-control systems. Sysadmins are advised to block these from access by their users. ®

Sponsored:
Quit your addiction to storage

Article source: https://go.theregister.co.uk/feed/www.theregister.co.uk/2020/02/27/iran_revenge_cyberattacks_hacking_crew/

What Your Company Needs to Know About Hardware Supply Chain Security

In Dun Bradstreet’s 2019 “Compliance and Procurement Sentiment” report, respondents cited cybersecurity as their top concern, yet 48% had not integrated associated risks into their third-party risk management. While developing and implementing a supply chain security program can be daunting, it should be the first item on your company’s to-do list — with an emphasis on hardware security, which is often given short shrift.

Information security programs typically focus on managing software patches and keeping anti-malware engines and network security gear up to date. As a result, hardware components are often deprioritized, even though they are also vulnerable to advanced attackers and nation-state threats. The manipulation of physical components during building stages or transportation routes is a threat to all physical products. Faulty parts cause recalls, and when the part is relied on by global systems and contains sensitive data, the scale of the potential carnage becomes exponential. Successfully attacking firmware can create a vulnerability that attackers covet because, unlike most software-based attacks that can be fixed by resetting a device back to default, many hardware attacks can survive firmware reflashing or operating system reinstallations.

Threats to the hardware supply chain are not theoretical, and security teams need to develop stronger policies to mitigate supply chain threats and risks. Securing the supply chain needs to happen at various levels — each carrying its own complexities. The first step is ensuring the supply chain is part of your organization’s threat model. At a minimum, a good grasp of the risks associated with the supply chain could change your acceptable business risks.

Here are 10 best practices for designing a strong supply chain security program.

1. Perform a risk analysis of the business: Risk is defined as the cost of system loss multiplied by the probability that the loss may occur through malicious action. Such a risk analysis can help an organization triage incidents and prioritize mitigations. Rooting out hardware implants from the supply chain is an expensive process, and a risk analysis can weigh the benefits of implementing the controls in this list against the cost of a security incident. It may not make sense for every organization, or every business unit inside an organization, to prioritize threats from hardware implants. Determine your team’s risk analysis first before implementing any security measures.

2. Create and maintain an inventory of third-party hardware providers: This should be an extension of the hardware and software inventory already dictated by your organizational policy.

3. Identify the devices that provide business-critical functionality and services: Critical devices are defined as any hardware that is a single point of failure in an organization’s security model or that implements a critical security-relevant service.

4. Perform a third-party risk assessment on each critical provider/device: If necessary, once the assessment is complete, re-evaluate contractual language to include security addendums and clauses around mandates that your service provider maintains and a request for periodic proof of its continued adherence to security standards.

5. Establish a communication plan with each critical provider: This should be bidirectional and allow each organization to be informed when issues arise that could increase exposure to risk.

6. Build and maintain a software dependency tracker for your organization’s hardware: Through this, you can determine whether servers or appliances are vulnerable to security flaws in software components and initiate discussions with vendors about timely patching.

7. Establish an assessment process for third-party hardware that is delivered to your organization: This can include testing the security of your hardware, establishing traffic baselines in a lab environment, and reviewing the security of your supplier’s supplier.

8. Conduct ingress and egress filtering: Do this on any network-attached components, blocking unexpected requests from entering or leaving the operating environment.

9. Request documentation and proof of assessment for devices that implement critical infrastructure: Devices should be resilient to, and subjected to, network, local, and physical attacks. To specifically resist hardware implants, anti-tamper controls should be tested and reverse-engineering efforts against devices should be limited through technical controls.

10. Understand your vendors’ supply chains as part of the system selection process: Vendors should be able to share the origin of each device component and provide an overview of how the component is secured from manufacturer to customer.

Though these recommendations cannot totally prevent the compromise of mission-critical hardware, they are a foundation to help mitigate your overall risk.

Hardware interdiction is a real threat, and supply chain security assessments must be part of most organizations’ threat models and risk mitigation strategies. Hardware attacks are unique in that they provide access and persistence at levels that are challenging and near-impossible to adequately address. By establishing a process and framework for addressing these concerns, you can ensure you’re not giving more advanced attackers carte blanche to your environment.

Related Content:

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s featured story: “How to Prevent an AWS Cloud Bucket Data Leak.”

Daniel Wood (CISSP, GPEN) is the Associate Vice President of Consulting at Bishop Fox, where he leads all service lines and develops strategic initiatives. He has over 15 years of experience in cybersecurity and is a subject matter expert in red teaming, insider threat, and … View Full Bio

Article source: https://www.darkreading.com/endpoint/what-your-company-needs-to-know-about-hardware-supply-chain-security-/a/d-id/1337084?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Intel Analyzes Vulns Reported in its Products Last Year

A new Intel report looks at the more than 250 CVEs affecting Intel products in 2019.

RSA CONFERENCE 2020 – San Francisco – In 2019, Intel published 236 CVEs (Common Vulnerability and Exposures) vulnerabilities from its various products. The company today issued a report that analyzed those CVEs on the type, severity, and source as part of Intel’s pledge of providing greater transparency in its bug discovery and disclosure process.

Jerry Bryant, director of security communication in the Intel Platform Assurance and Security group, said one of the things that struck him as he went through the list of CVEs was where they came from: “144 of the 236 CVEs were discovered internally, by Intel employees,” said Bryant, who authored Intels 2019 Product Security Report. Of the rest, he says, 70 were found through the Intel Bug Bounty program.

Between internal discoveries and those made through the bounty program, Bryant says that 91% of the CVEs were generated by researchers associated in some way with Intel.

Scale of Severity

The Common Vulnerability Scoring System (CVSS) ranks the severity of vulnerabilities and allows that severity to be communicated among teams and individuals. Ranking vulnerabilities on a scale from 0 to 10, 3.9 and below is low, 9.0 and above is critical; and 4.1 – 9.9 are low, medium, and high depending on the precise score.

Of the 236 CVEs in 2019, only four were critical, while 151 were low or medium severity. All of the critical CVEs were found in the Baseboard Management Controller (BMC), used for server remote monitoring and control, and the Converged Security Manageability Engine (CSME), a low-power processor and operating system for security tasks that runs in parallel with the main CPU.

And what about the CPU and the “speculative execution, side-channel” vulnerabilities that have been so much in the news after Spectre and Meltdown? There were 11 CVEs related to the architectural issues last year, representing less than 5% of the total. Those CPU CVEs averaged a CVSS of 5.02, earning an aggregate “medium” severity score.

According to the Intel report, “These microarchitectural side channel vulnerabilities are often closely related, generally difficult to exploit and to Intel’s knowledge, have not been successfully utilized outside of a controlled lab environment at the time of this report.”

Related Content:

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s featured story: “How to Prevent an AWS Cloud Bucket Data Leak.”

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/intel-analyzes-vulns-reported-in-its-products-last-year/d/d-id/1337178?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

How We Enabled Ransomware to Become a Multibillion-Dollar Industry

As an industry, we must move beyond one-dimensional approaches to assessing ransomware exposures. Asking these four questions will help.

Ransomware has been around for more than 15 years, yet it continues to be the most pervasive cyberthreat facing businesses. According to reports, in 2019 alone more than 966 government agencies, educational establishments, and businesses in the US were hit by ransomware attacks, at a potential cost exceeding $7.5 billion. And, unfortunately, when organizations choose to pay a ransom, they are adding fuel to the fire by supporting this global criminal industry.

The US is home to the world’s leading technology companies, so why haven’t we solved the ransomware problem by now? The answer is simple: We underestimated the challenge of finding and fixing software vulnerabilities used by ransomware. In the process, we created the perfect environment for a pandemic to take hold and thrive.

For the vast majority of organizations, both large and small, locking the windows and doors used by ransomware in their corporate networks is beyond their capabilities. But it’s not for lack of trying.

Most companies routinely perform unauthenticated scans of devices on their IT network looking for vulnerabilities. But unauthenticated scans do not detect as many vulnerabilities as security scans performed as a logged-in (authenticated) user. Of the vulnerabilities they find, companies typically strive to fix the ones ranked as critical or high in severity, primarily to reduce the number of fixes, or patches, that need to be applied. Fixing “every” security vulnerability is beyond the reach of even the largest and best-resourced companies in the world.

However, due to the complexity of the average corporate network, this approach creates a never-ending treadmill where companies are never able to successfully patch all of the critical and high-severity vulnerabilities before new ones are discovered.

Even eliminating all high-severity vulnerabilities doesn’t solve the problem because it means a large percentage of others (low and medium risk) are never evaluated for their potential to expose the company to a ransomware attack. For example, the high-severity selection criteria ignores the business criticality of affected devices. Are they running the company’s financial systems? Or are they reachable from the Internet?

In addition, the traditional high-severity ranking approach doesn’t take into account whether a particular vulnerability is being actively used by ransomware. Without a more comprehensive assessment of security vulnerabilities, it’s virtually impossible for companies to know how at risk they really are because of ransomware, and whether they are making forward progress against reducing their risk.

To get the best possible assessment of an organization’s risk of being victimized by ransomware, an authenticated scan — which determines how secure a network is from an inside (authenticated user’s) vantage point — is needed. While unauthenticated scans can probe a system and deliver a surprising amount of detail, they don’t see everything. For example, they will find a good number of vulnerabilities but may have to flag them as potential threats, since they lack the visibility to provide 100% certainty. With ransomware now targeting the application layer, it’s crucial that authenticated scans are used to validate whether a patch management program is doing its job and gather data needed to improve processes going forward.

Penetration testing is another important tool in the fight against ransomware and should be performed periodically. Beyond ransomware and other threats, this type of testing offers the important benefit of validating that your controls are working properly. However, like compliance assessments, a single penetration test provides only a point-in-time view of a company’s security posture. Continuous penetration testing is the proper approach.

As an industry, we must move beyond one-dimensional approaches to assessing ransomware exposures. Meanwhile, business leaders and boards should be asking for specifics pertaining to an organization’s security posture and exposure to ransomware attacks.

For example:

  • What is our organization’s risk of being compromised by a ransomware attack?
  • How do we measure our exposure to being victimized by ransomware?
  • What steps are we taking to proactively lower our risk to ransomware attacks?
  • How are we monitoring our progress toward lowering ransomware risk on an ongoing basis?

This line of inquiry will enable the C-suite to assess whether the organization is being reactive or proactive toward the ransomware threat and help understand whether additional investments are required to reduce the company’s attack surface.

Related Content:

 

Dr. Srinivas Mukkamala is co-founder and CEO of RiskSense and a former advisor to the U.S. Department of Defense and U.S. Intelligence Community. He is an expert on malware analytics, breach exposure management, web application security, and enterprise risk reduction. Dr. … View Full Bio

Article source: https://www.darkreading.com/risk/how-we-enabled-ransomware-to-become-a-multibillion-dollar-industry/a/d-id/1337101?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Facebook bans coronavirus ‘miracle cure’ ads

Does drinking bleach cure the coronavirus?

NO. Not unless by “cure” you really mean “will potentially kill you before Coronavirus Disease 2019 (COVID-19) has a chance to.”

That’s why, following the World Health Organization (WHO) having declared COVID-19 a public health emergency of international concern, Facebook late last month said it would help by trying to limit the spread of nonsense on its platform, including, for example, snakeoil posts about the fake miracle bleach cure.

On Tuesday, Facebook took it a step further. As Business Insider reported, the platform plans to ban ads that promise to cure the contagious illness or that try to “create a sense of urgency” about it.

Facebook says it’s also going to take down fake news about the virus entirely if posts put people at risk.

Fearmongering has already got people running for the exits – or, in this case, price-gouging face masks on Amazon and flocking to Facebook groups to buy medical masks in bulk.

According to MarketWatch, as of Wednesday, the COVID-19 tally was up to 81,245 confirmed cases worldwide and at least 2,770 deaths.

Facebook sent Business Insider this statement about its plans to limit the panic:

We recently implemented a policy to prohibit ads that refer to the coronavirus and create a sense of urgency, like implying a limited supply, or guaranteeing a cure or prevention. We also have policies for surfaces like Marketplace that prohibit similar behavior.

Facebook will be using its third-party fact-checkers to filter out the dross and suppress it in its newsfeed, as it’s done in the past with the “miracle cure” posts we all hate. In its January announcement, it said it would remove any false information about the outbreak that’s been “flagged by leading global health organizations and local health authorities that could cause harm to people who believe them.”

From the 30 January post:

We are doing this as an extension of our existing policies to remove content that could cause physical harm.

Facebook said it’s focusing on claims designed to discourage people from seeking treatment or taking appropriate precautions.

That includes false cures or prevention methods or claims that create confusion about available health resources.

Facebook will also block or restrict hashtags used to spread misinformation on its Instagram platform, and, as of late January, was conducting proactive sweeps to find and remove as much misleading or false content as possible.

Besides the posts that could harm people physically, concern over the illness has attracted those humans who like to take advantage of emergencies to spread their own brands of digital infection.

As it is, the Sophos Security Team has already seen a fake “safety measures” email, purporting to be from the WHO, that turned out to be a phishing scam.


Latest Naked Security podcast

LISTEN NOW

Click-and-drag on the soundwaves below to skip to any point in the podcast.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/9dojXZGW3Is/

Chrome 80 encryption change blocks AZORult password stealer

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.

Credential drought

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.

Are browser password managers safe?

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.


Latest Naked Security podcast

LISTEN NOW

Click-and-drag on the soundwaves below to skip to any point in the podcast.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/kjIQgx4g7bk/

Brave beats other browsers in privacy study

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.


Latest Naked Security podcast

LISTEN NOW

Click-and-drag on the soundwaves below to skip to any point in the podcast.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/nYYmchFylNA/

S2 Ep28: Stalkerware, when cybercrooks return, and phishing gone wild – Naked Security Podcast

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.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/M-uTiBQXpSE/

If you’re serious about browser privacy, you should probably pass on Edge or Yandex, claims Dublin professor

Microsoft Edge and Yandex are “much more worrisome” compared to Brave, Chrome, Firefox and Safari, according to a paper on browser privacy (PDF) published this week.

Douglas J Leith, a comp sci professor at Trinity College Dublin, investigated the network activity of six browsers – Google Chrome, Mozilla Firefox, Apple Safari, Brave, Microsoft Edge and Yandex – using a proxy to capture encrypted traffic.

Using a default install, he inspected the data sent when first starting the browser, as well as data transferred when navigating to a web page by pasting a URL into the address bar and by typing the URL – the latter being interesting because it may use a cloud-driven autocomplete feature. All the tests were conducted on a Mac, even for Edge. Finally, he checked on activity when the browsers where left idle for 24 hours.

In the paper, Leith said: “We find that the browsers split into three distinct groups from this privacy perspective. In the first (most private) group lies Brave, in the second Chrome, Firefox and Safari and in the third (least private) group lie Edge and Yandex.”

The, er, borne identity

Is Edge really worse than Chrome – the latter being from one of the biggest data collectors in the business? The problem, according to Leith, is to do with identifiers that browsers send to the vendors to enable different searches and sessions to be tied together.

“Edge and Yandex both use hardware identifiers,” he said. “That’s tied to the physical hardware of the device and can’t easily be changed. Whereas Chrome and Firefox use identifiers that are essentially random numbers generated when the browser first starts.” The Chrome and Firefox identifiers do persist between sessions, but are reset if you do a fresh install. Leith explained that to ensure a true fresh install, he deleted configuration data left behind in the user profile.

We suggested to Leith that most users, if they ever reinstall their browsers, will not bother with deleting user profile data, in which case the difference between the identifiers melts away. “Absolutely – if you leave your profile around, then some of the identifiers are tied to the browser,” he told us.

There is also the matter of what happens if users log into Google, Microsoft, Apple or Firefox services while using the browser. “If you log on to Google or Apple services through the browser, of course it’s all integrated together,” he said.

But the focus of Leith’s research is on what happens with a default install where you choose not to log on. How private is your browsing history?

Leith started by pasting (not typing) an URL into the browser’s top bar. In the case of Chrome: “This generates a request to www.google.com/complete/search with the URL details (i.e. http://leith.ie/nothingtosee.html) passed as a parameter and also two identifier-like quantities (psi and sugkey).” Similarly, Edge sent the URL to the Bing autocomplete API complete with identifying cookie. Yandex also transmitted the URL to its own servers before navigation. Firefox, Brave and Safari did not collect any data from a pasted URL.

What if the user types into the browser? In this respect, the URL or search autocomplete feature is key. Browsers used to distinguish between URLs and searches, but this distinction has largely been lost in favour of a single Omnibox, as Google calls it, which works as a search box unless you type a full and properly formed URL. Most users do not bother, which means web navigation is largely driven by search, plus a few bookmarked sites.

“Safari has the most aggressive autocomplete behaviour, generating a total of 32 requests to both Google and Apple,” Leith reported. “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.

“Chrome is the next most aggressive, generating 19 requests to a Google server which, once again, include an identifier that persists across browser restarts.

“Firefox is significantly more private, sending no identifiers with requests and terminating requests after the first word, so generating a total of 4 requests. Better still, Brave disables autocomplete by default and sends no requests at all as a user types in the top bar.”

Edge, on the other hand, “sends text to www.bing.com as it is typed. A request is sent for almost every letter typed, resulting in a total of 25 requests. Each request contains a cvid value that is persistent across requests although it changes across browser restart.”

The key point here is that in some cases the vendor and/or search provider gets all the data they need to construct a user’s browsing history. Why does this matter? “The user’s browsing history is generally seen as being sensitive data,” Leith told us. “It’s about a person’s interests, it’s fine-grained. Sharing that with a third party without clear knowledge and consent seems like a privacy problem.”

Do users consent when they agree a privacy policy? Leith said that while users often have to agree to terms and conditions when downloading or installing, it is “the usual 20 pages of detailed things that no one looks at” – there’s a question around whether that is informed consent. “Is it presented in a sufficiently clear way?” Leith asked. “On firing up these browsers, there’s no consent at that point.” He would like users to be offered an opt-out along with clear information about the implications of search and autocomplete in the browser.

Leith’s study is narrow, though he does demonstrate significant differences between browsers. Whether Edge is worse than Chrome is open to debate, but Edge, Yandex, Chrome and Safari seem to lead the field in terms of calling home with a user’s browsing data. Mozilla’s FireFox seems better, and Brave better still. Other relevant questions are how the user’s search history data is used by the companies that collect it, and what is the impact when users sign in, in order to get the benefit of synchronised bookmarks and indeed browser history across different devices.

Leith is right to highlight the significance of the search/autocomplete feature, which is now standard in most web browsers, and its potential to give away our browsing history even when not logged in to any service.

Mozilla gave us the following comment: “Mozilla publicly documents our data practices and we have a public data review process. Browsing history is only sent to Mozilla if a user turns on our Sync service, whose purpose is to share data across a user’s devices. Unlike other browsers, Sync data is end-to-end encrypted, so Mozilla cannot access it.

“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.” ®

Sponsored:
Detecting cyber attacks as a small to medium business

Article source: https://go.theregister.co.uk/feed/www.theregister.co.uk/2020/02/27/edge_and_yandex_lead_hall_of_browser_privacy_shame_says_dublin_professor/

Sophos was gearing up for a private life – then someone remembered the bike scheme

Today was meant to be Brit security biz Sophos’s last day on the London Stock Exchange following its £3bn purchase by a US venture capital company.

But there’s been a bump in the road, a stick in the wheel, because Sophos was a member of the UK government’s “cycle to work” scheme – which offers staff loans to pay for bicycles and related stuff like lights, helmets and panniers.

The trouble is that the bike scheme is regulated by the Financial Conduct Authority. So anyone taking control of Sophos needs to clear its obligations under the cycle scheme with the FCA. And someone took their eye off the ball and didn’t spot this. This will likely be a textbook example of due diligence, the process that sees hordes of overpaid junior lawyers and accountants poring over every tiny detail of a business before going ahead with a merger or takeover.

According to a statement posted to the Regulatory News Service, the feckup was only noticed yesterday:

During the course of 26 February 2020, Bidco became aware that a subsidiary of Sophos, Sophos Limited, has a limited regulatory permission from the UK Financial Conduct Authority (the “FCA”) to enable it to provide finance to employees for the purchase of cycles or cyclist safety equipment under the UK Government’s “cycle to work” scheme, a tax efficient scheme for employees. Under UK financial regulation, a company which is able to offer equipment under the scheme with a value in excess of £1000 must be authorised by the FCA. Sophos Limited has currently extended arrangements with a value in excess of £1000 to a de minimis number of employees. Under UK financial regulation, any person acquiring control of an authorised entity must seek the FCA’s approval.

So for now the firm’s shares remain on the exchange. An updated timetable will be released in due course, it has said.

Sophos is a venerable member of the UK software world, having been around since the 1980s. It was founded in Oxfordshire in 1985, claims 100 million customers around the world, 370,000 businesses and over 47,000 channel partners. Although best known as an endpoint security provider, it also offers network and cloud products and managed services.

It is being bought by Surf Buyer Limited – a vehicle owned by VC firm Thoma Bravo, which also owns McAfee, bits of Symantec, and Barracuda Networks. They went public about the £3bn deal in October.

The FCA refused to comment and Sophos declined to say anything further beyond its regulatory filing. ®

Sponsored:
Detecting cyber attacks as a small to medium business

Article source: https://go.theregister.co.uk/feed/www.theregister.co.uk/2020/02/27/sophos_selloff_stopped_by_bike_scheme/