The XZ Utils hack attempts to exploit the way open source software development usually works.
Canberra:
Outside the world of open source software, few people may have heard of XZ Utils, a small but widely used data compression tool in Linux systems. But late last week, security experts discovered a serious, intentional flaw that could leave networked Linux computers vulnerable to malicious attacks.
This flaw has been identified as a critical issue that could allow knowledgeable hackers to gain control of vulnerable Linux systems. Because Linux is used in email, web servers and application platforms around the world, this vulnerability could allow an attacker to silently access important information saved on computers around the world – possibly including the one you are reading this on right now. equipment.
Major software vulnerabilities such as the SolarWinds hack and the Heartbleed vulnerability are nothing new, but this one is something different.
The XZ Utils hack attempts to exploit the way open source software development usually works. Like many open source projects, XZ Utils is an important and widely used tool that is maintained primarily by a volunteer in his spare time. This system has created tremendous benefits for the world in the form of free software, but it also poses unique risks.
Open Source and XZ Utils
First, a brief review of open source software. Most commercial software, such as the Windows operating system or the Instagram app, are “closed source” – meaning no one but its creator can read or modify the source code. In contrast, “open source” software’s source code is public and people are free to do what they like with it.
Open source software is very common, especially in terms of the “nuts and bolts” of the software that consumers don’t see, and have tremendous value. A recent study estimated the total value of open source software in use today at $8.8 trillion.
Until about two years ago, the XZ Utils project was maintained by a developer named Lasse Collin. Around that time, an account named Jia Tan submitted improvements to the software.
Soon after, a number of previously unknown accounts popped up reporting bugs and submitting feature requests to Collin, putting pressure on him to hire an assistant to maintain the project. Jatan is the logical candidate.
Over the next two years, Jatan became increasingly involved, and we now know that he introduced a carefully hidden weapon into the software’s source code.
The modified code secretly altered another piece of software, a ubiquitous cybersecurity tool called OpenSSH, to deliver malicious code to the target system. Therefore, a given intruder will be able to run any code they like on the target computer.
The latest version of XZ Utils containing the backdoor will be included in popular Linux distributions and rolled out globally. However, it was discovered just in time when a Microsoft engineer investigated some minor memory anomalies on his system.
Quick response
What does this incident mean for open source software? Well, despite it initially seeming so, this doesn’t mean that open source software is unsafe, unreliable, or untrustworthy.
Since all code is available for public review, developers around the world can quickly begin analyzing the history of the backdoor and its implementation. These efforts can be logged, distributed, and shared, and specific pieces of malicious code can be identified and removed.
A response of this magnitude would not be possible using closed source software.
Attackers would need to take a somewhat different approach to attacking closed source tools, perhaps impersonating company employees over time and exploiting the weaknesses of closed source software production systems (e.g. bureaucracy, hierarchy, unclear reporting lines, and poor knowledge sharing) .
However, if they did implement such a backdoor in proprietary software, there would be no opportunity for large-scale distributed code auditing.
Lessons to Learn
This case is a valuable opportunity to learn about different types of weaknesses and vulnerabilities.
First, it shows how easily online relationships between anonymous users and developers can become toxic. In fact, attacks depend on the normalization of these toxic interactions.
The social engineering portion of the attack appears to have used anonymous “socks” accounts to create guilt and emotionally force the main maintainer to accept small, seemingly innocuous code additions over a period of several years, forcing them to cede development control to Jia Tan.
One user account complained:
You’re ignoring a lot of rotten patches on this mailing list. Now you kill your repo.
When the developer claimed to have mental health issues, another account accused:
I’m sorry for your mental health issues, but it’s important to know your limits.
These comments may seem innocuous individually, but when taken together they turn into a mob.
We need to help developers and maintainers better understand the human aspects of coding and the social relationships that influence, underpin, or determine how distributed code is produced. There is still much work to be done, especially to raise awareness of the importance of mental health.
The second lesson is the importance of recognizing “obfuscation,” a process often used by hackers to make software code and processes difficult to understand or reverse engineer. Many universities don’t teach it as part of standard software engineering courses.
Third, some systems may still be running dangerous versions of XZ Utils. Many popular smart devices such as refrigerators, wearables, and home automation tools run on Linux. These devices often reach an age where it is no longer financially feasible for manufacturers to update the software, meaning they do not receive patches for newly discovered security vulnerabilities.
In the end, whoever was behind the attack—some speculated he may have been a state actor—had free access to various code bases for two years to conduct careful and patient deception. Even now, adversaries learn from how system administrators, Linux distribution producers, and code base maintainers react to attacks.
Where to go from here?
Code maintainers around the world are now thinking about their vulnerabilities on a strategic and tactical level. Not only will they worry about the code itself, but also the code distribution mechanism and software assembly process.
My colleague David Lacey, director of the nonprofit cybersecurity organization IDCARE, often reminds me that a statement from the IRA is a good example of the situation facing cybersecurity professionals. After the failed bombing of the Brighton Hotel in 1984, the terrorist group grimly declared:
We are unlucky today, but remember, we only have to be lucky once. You must always be lucky.
(Author: Sigi Goode, Professor of Information Systems, Australian National University)
(Disclosure statement: Sigi Goode does not work for, consult, own shares in, or receive funding from any company or organization that would benefit from this article, and has disclosed no relevant relationships beyond his academic appointment)
This article is republished from The Conversation under a Creative Commons license. Read the original article.
(Except for the headline, this story has not been edited by NDTV staff and is published from a syndicated feed.)
Follow us on Google news ,Twitter , and Join Whatsapp Group of thelocalreport.in
