ภัยคุกคามที่น่าสนใจบนแพลตฟอร์ม Linux มีอะไรบ้าง? คุยกับนักวิจัยมัลแวร์ ESET Senior Malware Researcher คุณ Marc‑Etienne M.Léveillé ผู้เปิดเผยมัลแวร์ที่โจมตีเซิร์ฟเวอร์ Linux
ก่อนนี้ Linux เป็นเหมือนแพลตฟอร์มที่เจาะไม่ได้ แต่ด้วยจำนวนผู้ใช้เพิ่มมากขึ้นทำให้เหล่าแฮกเกอร์หันมาศึกษาและเริ่มสร้างโปรแกรมอันตรายหรือมัลแวร์ เพื่อโจมตีผู้ใช้บนแพลตฟอร์มนี้ อีกปัญหาก็คือผู้ดูแลระบบ Linux ไม่มีความรู้ในการรับือกับภัยคุกคามบน Linux มาก่อน
วันนี้เราเลยนำบทสัมภาษณ์กับคุณ Marc‑Etienne M.Léveillé ว่าด้วยเรื่องของความปลอดภัยบน Linux
You’ve spent years hunting down malware that infiltrates Linux-based servers. Would you first give us a helicopter view of the Linux malware threatscape in early 2020?
The Linux malware threat landscape for 2020 is pretty similar to what we’ve seen over the last few years. We know that Ebury, the OpenSSH backdoor used in Operation Windigo, is still being updated and used in the wild in 2020. New samples were seen over the last month. A few years ago, there was also a spike in Linux malware targeting routers and other Linux-based peripherals – for example, Mirai and all its variants, and Moose. We hear less about these threats lately and I hope it’s because internet service providers (ISPs) and vendors have done a better job of securing these devices and are avoiding exposing remote administration access with default passwords.
We have yet to find a campaign as sophisticated as the Windigo Operation we documented more than five years ago. It doesn’t mean there isn’t one; maybe the perpetrators are getting better at staying under the radar?
What are the key threats facing Linux servers?
The threats depend mostly on the services provided by the servers. For example, if a popular web site is compromised, it could be used to redirect traffic, perform a watering-hole attack to compromise its visitors, or steal submitted form data. We’re also observing lots of spam being sent by what appear to be compromised servers. Something we are seeing more now than a few years back is the spreading of cryptocurrency miners. It’s a simple way to monetize a Linux botnet without interfering too much with the legitimate host’s services.
What’s changed since you first analyzed Linux malware?
We are seeing more groups performing targeted attacks that also have Linux malware in their arsenal. This goes beyond the usual crimeware campaigns we were seeing that were used for financial gain. For example, it was discovered last year that the Winnti Group, known for both espionage and financially motivated campaigns, has Linux variants of their backdoor. This was disclosed by Kaspersky during SAS and analyzed by Chronicle a few weeks later. Other good examples are the cross-platform Xagent backdoor by the Sednit group and Kamino, an OpenSSH backdoor used by Carbanak.
Some of the campaigns you helped uncover had stayed under the radar for years. Why? Do you think this may also be changing?
It’s hard to say if there are more campaigns that are under the radar, because we still don’t know the unknowns. What I mean is that it’s very likely that there are multiple Linux botnets out there that are still undocumented. How many? More or fewer of them than before? Those are difficult questions to answer without metrics.
How does the lack of telemetry with respect to Linux malware hamper your work?
Only a small percentage of users install security products on Linux systems. This means it’s hard to determine the prevalence of a Linux threat: are the numbers low because samples sizes are small or is it because this threat is uncommon? This problem isn’t vendor specific: there’s a general trend to treat Linux systems differently, sometimes for good reasons, but I think most of the time for poor reasons.
Whenever new malware targeting Linux is discovered, Linux users seem surprised and tend to deny the problem. Do you think Linux is more secure than the other operating systems?
A lot of people think of Linux as an operating system with superior security compared to all the others. In 2020, I don’t think this is something that we can assert. Both Microsoft and Apple have put lots of effort into securing their platforms. For example, embedded code signatures in executable files and enforcing valid signatures for key system and device driver functionality is something that’s been available on Windows and macOS for years, while on Linux, it still is not widespread. I’m not saying Linux is insecure, but rather, like the other platforms, it has its strengths and weaknesses and certainly should not be considered bulletproof.
Is there anything that sets Linux-based malware apart from malicious code that targets other operating systems? Anything of note in terms of stealth, obfuscation, armoring, persistence…?
Compared to Windows malware, Linux malware tends to be less obfuscated and easier to analyze. Obfuscation is often added to evade detection by security products. Since there are often no security products to bypass, the bar is lower and attackers skip this unnecessary step. I’m not saying that all Linux malware is easy to analyze and none is obfuscated; I am saying that on average the bar is lower.
When a Linux server is compromised, malware persistence is not as much of an issue as on other systems. Servers tend to have very high uptimes and reboots are far less frequent than on desktop or laptop computers. As a result, in general Linux malware tends to lack persistence mechanisms.
What are the most common attack vectors for compromising Linux servers?
I think vulnerabilities in web applications remain one of the most common attack vectors for compromising Linux servers. However, we’ve seen vulnerabilities being disclosed in the past few years on services that are very popular such as the Exim mail server (CVE-2019-10149). Exploitation of this vulnerability was quite easy and we saw lots of attempts to use it to propagate malware right after it was disclosed.
What are the best ways to prevent such infiltrations?
I know it may sound like a broken record … but keeping software up to date is still one of the key recommendations. For production servers running a Linux distribution with long-term support, it’s preferred to be sure to have security patches available without having to update the full operating system and risking breaking production services.
Enabling two-factor authentication (2FA) on SSH is also a good recommendation, especially if the system is reachable from the internet. 2FA will protect the server if credentials are stolen or reused.
To avoid pivoting from one service to another, isolating services is also a good practice. For example, hosting an unmaintained blog on the same system as a website where financial transactions are processed poses a risk, since compromising the blog may result in compromising the transactional website.
Five years ago, you said that the lack of Linux forensic knowledge is the main problem for sysadmins. Has this changed?
I think this is still a problem, but the root cause of this is also the lack of time allotted to securing systems, compared to developing new ones. Similarly, the effort spent on training internal staff about security is often minimal. It’s nothing new that security is often seen as an expense. This is not a Linux-specific problem. However, that expense would suddenly seem worthwhile if an incident occurs.
Let’s now turn our attention to your upcoming workshop at RSA. Would you give us a sneak peek into your activities there?
This will be my first time at RSA. I hope to present some interesting technical content there in the form of a hands-on workshop and a presentation on Thursday during the event.
The workshop will be open during the full week of RSA and only requires you to have a computer with a web browser, the OpenVPN client and an SSH client. It is made to feel as close to a real situation as possible: the server is actively compromised using a vulnerable service, malware talks to a C&C server, etc. Come visit us at the ESET booth to gain access to the workshop.
My presentation will sum up various Linux tools commonly available to investigate a breach. It’s important to understand what data and metadata are available and how to query and analyze them. I will explain how these tools were useful in real incidents we’ve worked on.
Author: Tomáš Foltýn
Translated by: Worapon H.