<h2 id="overview">Overview</h2>
<p>It&rsquo;s the end of the year for official duties for the Ubuntu Security team so we
take a look back on the security highlights of 2024 for Ubuntu and predict what is coming in 2025.</p>
<h3 id="2024-year-in-review-for-ubuntu-security--00-55">2024 Year in Review for Ubuntu Security (00:55)</h3>
<h4 id="full-disclosure-necromancy-with-zombie-cves">full-disclosure necromancy with zombie CVEs</h4>
<ul>
<li><a href="/episode-217/#full-disclosure-spammed-with-zombie-cves--09-52">full-disclosure spammed with zombie CVEs from Episode 217</a></li>
</ul>
<h4 id="development-of-unprivileged-user-namespace-restrictions-for-ubuntu-24-dot-04-lts">Development of unprivileged user namespace restrictions for Ubuntu 24.04 LTS</h4>
<ul>
<li><a href="/episode-218/#updates-for-unprivileged-user-namespace-restrictions-in-ubuntu-24-dot-04-lts--10-32">Updates for unprivileged user namespace restrictions in Ubuntu 24.04 LTS from Episode 218</a></li>
</ul>
<h4 id="linux-kernel-becomes-a-cna">Linux kernel becomes a CNA</h4>
<ul>
<li><a href="/episode-219/#linux-kernel-becomes-a-cna--11-25">Linux kernel becomes a CNA from Episode 219</a></li>
<li><a href="/episode-220/#follow-up-to-linux-kernel-cna--11-40">Follow up to Linux kernel CNA from Episode 220</a></li>
</ul>
<h4 id="ubuntu-participates-in-pwn2own-vancouver">Ubuntu participates in Pwn2Own Vancouver</h4>
<ul>
<li><a href="/episode-223/#summary-of-pwn2own-vancouver-2024-results-against-ubuntu-23-dot-10--08-05">Summary of Pwn2Own Vancouver 2024 results against Ubuntu 23.10 from Episode 223</a></li>
</ul>
<h4 id="xz-utils-ssh-backdoor-supply-chain-attack">xz-utils / SSH backdoor supply-chain attack</h4>
<ul>
<li><a href="/episode-224/#xz-utils-backdoor-and-ubuntu">xz-utils backdoor and Ubuntu from Episode 224</a></li>
<li><a href="/episode-225/#update-on-xz-utils--15-18">Update on xz-utils from Episode 225</a></li>
</ul>
<h4 id="linux-security-summit-na-and-eu">Linux Security Summit NA and EU</h4>
<ul>
<li><a href="/episode-226/#linux-security-summit-na-2024--07-22">Linux Security Summit NA 2024 from Episode 226</a></li>
<li><a href="/episode-237/#linux-security-summit-europe-2024--03-44">Linux Security Summit Europe 2024 from Episode 237</a></li>
</ul>
<h4 id="release-of-ubuntu-24-dot-04-lts">Release of Ubuntu 24.04 LTS</h4>
<ul>
<li><a href="/episode-227/#ubuntu-24-dot-04-lts--noble-numbat--released--14-27">Ubuntu 24.04 LTS (Noble Numbat) released from Episode 227</a></li>
</ul>
<h4 id="regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh">regreSSHion remote unauthenticated code execution vulnerability in OpenSSH</h4>
<ul>
<li><a href="/episode-232/#deep-dive-into-regresshion-remote-unauthenticated-code-execution-vulnerablity-in-openssh">Deep-dive into regreSSHion - Remote Unauthenticated Code Execution Vulnerablity in OpenSSH from Episode 232</a></li>
</ul>
<h4 id="various-other-high-profile-vulnerabilities">Various other high profile vulnerabilities</h4>
<ul>
<li><a href="/episode-234/#discussion-of-cve-2024-5290-in-wpa-supplicant--16-10">Discussion of CVE-2024-5290 in <code>wpa_supplicant</code> from Episode 234</a></li>
<li><a href="/episode-242/#deep-dive-into-needrestart-local-privilege-escalation-vulnerabilities">Deep dive into needrestart local privilege escalation vulnerabilities from Episode 242</a></li>
</ul>
<h4 id="ubuntu-windows-dual-boot-regression">Ubuntu/Windows Dual-boot regression</h4>
<ul>
<li><a href="/episode-235/#reports-of-dual-boot-linux-windows-machines-failing-to-boot--04-30">Reports of dual-boot Linux/Windows machines failing to boot from Episode 235</a></li>
</ul>
<h4 id="apparmor-based-snap-file-prompting-experimental-feature">AppArmor-based snap file prompting experimental feature</h4>
<ul>
<li><a href="/episode-236/#ubuntu-security-center-with-snapd-based-apparmor-home-file-access-prompting-preview--05-45">Ubuntu Security Center with snapd-based AppArmor home file access prompting preview from Episode 236</a></li>
<li><a href="/episode-237/#official-announcement-of-permissions-prompting-in-ubuntu-24-dot-10--09-00">Official announcement of Permissions Prompting in Ubuntu 24.10 from Episode 237</a></li>
</ul>
<h2 id="predictions-for-2025--14-35">Predictions for 2025 (14:35)</h2>
<ul>
<li>Increased use of AI to both spam projects with hallucinated CVEs (e.g. <a href="https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-for-intelligence/">curl</a>)
but also to &ldquo;aid&rdquo; in dealing with that spam
<ul>
<li>as the shine wears of AI likely expect OSS projects to ban contributions
generated with the aid of AI - whether CVE reports or code</li>
<li>but also expect companies to try and prove the worth of AI by finding novel
vulns -
e.g. apparent first 0-day discovered with AI doing vuln research
<a href="https://googleprojectzero.blogspot.com/2024/06/project-naptime.html">https://googleprojectzero.blogspot.com/2024/06/project-naptime.html</a></li>
<li>also more expected uses of AI like automating tasks used in the process of
security-related SW dev - automatically generating fuzz targets and then
improving the fuzz targets via AI as well
<a href="https://security.googleblog.com/2024/11/leveling-up-fuzzing-finding-more.html">https://security.googleblog.com/2024/11/leveling-up-fuzzing-finding-more.html</a></li>
</ul>
</li>
<li>More malware targeting Linux
<ul>
<li>didn&rsquo;t mention it earlier but we covered a number of Linux malware teardowns
this year and expect that trend to increase as Linux keeps growing in
popularity</li>
</ul>
</li>
<li>Full LSM stacking still won&rsquo;t make it into the upstream Linux kernel</li>
<li>Integrity of code and data will play more of a role
<ul>
<li>both in terms of software supply chain and integrity of distro repos etc,
but also efforts to try and guarantee the integrity of a Linux system
itself - whether via new <a href="https://docs.kernel.org/next/admin-guide/LSM/ipe.html">IPE LSM</a> or other mechanisms - mainstream distros
will start to care about integrity more</li>
</ul>
</li>
<li>More collaboration across distros to aid in efforts to collectively handle
deluge of CVEs</li>
<li>More efforts to try and fund OSS to learn from lessons of Heartbleed and xz-utils
<ul>
<li>some more and less successful</li>
</ul>
</li>
<li>More interesting vulns in more software
<ul>
<li>During 2024 Qualys have done some of the most interesting vuln research on
Linux - expect more from them and from others (whether aided by AI or not)</li>
</ul>
</li>
</ul>
<h2 id="get-in-contact">Get in contact</h2>
<ul>
<li><a href="mailto:security@ubuntu.com">security@ubuntu.com</a></li>
<li><a href="https://libera.chat">#ubuntu-security on the Libera.Chat IRC network</a></li>
<li><a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-hardened">ubuntu-hardened mailing list</a></li>
<li><a href="https://discourse.ubuntu.com/c/security">Security section on discourse.ubuntu.com</a></li>
<li><a href="https://fosstodon.org/@ubuntusecurity">@ubuntusecurity@fosstodon.org</a>, <a href="https://twitter.com/ubuntu_sec">@ubuntu_sec on twitter</a></li>
</ul>


<description>  It's the end of the year for official duties for the Ubuntu Security team so
  we take a look back on the security highlights of 2024 for Ubuntu and predict
  what is coming in 2025.
  </description>


        
          It's the end of the year for official duties for the Ubuntu Security team so
  we take a look back on the security highlights of 2024 for Ubuntu and predict
  what is coming in 2025.
  
        
        

  It's the end of the year for official duties for the Ubuntu Security team so
  we take a look back on the security highlights of 2024 for Ubuntu and predict
  what is coming in 2025.
  

Episode 243
          
          
          

<h2 id="overview">Overview</h2>
<p>This week we dive into the details of a number of local privilege escalation
vulnerablities discovered by Qualys in the needrestart package, covering topics
from confused deputies to the inner workings of the /proc filesystem and
responsible disclosure as well.</p>
<h2 id="deep-dive-into-needrestart-local-privilege-escalation-vulnerabilities">Deep dive into needrestart local privilege escalation vulnerabilities</h2>
<ul>
<li><a href="https://blog.qualys.com/vulnerabilities-threat-research/2024/11/19/qualys-tru-uncovers-five-local-privilege-escalation-vulnerabilities-in-needrestart">https://blog.qualys.com/vulnerabilities-threat-research/2024/11/19/qualys-tru-uncovers-five-local-privilege-escalation-vulnerabilities-in-needrestart</a></li>
<li><a href="https://www.qualys.com/2024/11/19/needrestart/needrestart.txt">https://www.qualys.com/2024/11/19/needrestart/needrestart.txt</a></li>
<li><a href="https://www.bleepingcomputer.com/news/security/ubuntu-linux-impacted-by-decade-old-needrestart-flaw-that-gives-root/">https://www.bleepingcomputer.com/news/security/ubuntu-linux-impacted-by-decade-old-needrestart-flaw-that-gives-root/</a></li>
<li>Qualys contacted <a href="mailto:security@ubuntu.com">security@ubuntu.com</a> on [2024-10-04 Fri]  to notify of 3
different local privilege escalation vulnerablities in needrestart</li>
<li>needrestart is system service, written in Perl, to automatically restart
system services if one of the libraries or the service itself was updated</li>
<li>installed by default on Ubuntu Server since 21.04 - so anyone using 22.04 LTS
(jammy) or 24.04 LTS (noble) would be affected - and is integrated into apt so
that it runs at the end of an apt install/upgrade/remove or via
unattended-upgrades (which again is installed by default to install security
updates automatically every 24 hours)</li>
<li>since it runs via apt it runs as root so if an unprivileged user can influence
it to execute code of their chosing, can achieve local privilege escalation
the next time it runs</li>
<li>Initially described these as:
<ul>
<li>trick needrestart into running the Python interpreter with an attacker controlled PYTHONPATH environment variable</li>
<li>win a race condition with needrestart to trick it into running with attacker
controlled Python interpreter instead of the system-installed one</li>
<li>perl-related vuln in the ScanDeps module where would open a filename
containing a pipe - which in turn causes Perl to execute a shell pipeline
with the filename as input and hence code execution</li>
</ul>
</li>
<li>needrestart is written in Perl so why is Python relevant?
<ul>
<li>basic functionality of needrestart is to look at the shared objects mapped
into memory of each process and match these against newly updated/installed
packages - if it sees that one of the shared objects for a given process got
updated it will then be restarted</li>
<li>back in 2014 introduced support for scanning files of interpreted languages for Java, Perl, Python and Ruby
<ul>
<li>uses <code>/proc/self/exe</code> to first identify the interpreter as say python</li>
<li>then looks at <code>/proc/self/cmdline</code> to determine the primary file being run
by the interpreter and from that looks at <code>import</code> statements to determine
which files are likely being used</li>
<li>uses similar approaches for the other interpreters</li>
</ul>
</li>
</ul>
</li>
<li>Interestingly it seems Qualys discovered this by accident - noticed the
message &ldquo;Scanning processes&hellip;&rdquo; whilst doing and apt upgrade and wondered what
that was - and if they controlled a process, whether they could then influence
the behaviour of it</li>
<li>For PYTHONPATH CVE, needrestart needs to replicate the behaviour of the Python
interpreter when it imports files
<ul>
<li>PYTHONPATH env var allows to specify a
custom path to import from - so needrestart looks this up from
<code>/proc/pid/environ</code> and executes the Python interpreter with this same value
to get it to resolve the imports to files on disk</li>
<li>But the unprivileged user is in control of this environment variable for their
process - classic case of a <a href="https://dl.acm.org/doi/10.1145/54289.871709">Confused Deputy</a> - lower privileged application is
able to trick a higher privileged application into misusing its authority on
the system - so can set their own PYTHONPATH, and since Python will happy load
any <code>__init__.so</code> files from that path, the attacker controlled shared object
is then executed by Python running as root via needrestart</li>
</ul>
</li>
<li>Initially Qualys suggested the Ruby implementation (which uses the <code>RUBYLIB</code>
env var) may also be affected and subsequently confirmed this to be the case</li>
<li>The second aforementioned vuln is also related to Python but instead of the
<code>PYTHONPATH</code> used by the interpreter, is about the interpreter binary itself
<ul>
<li>Before we said needrestart identified a process as using say Python by
looking at its <code>/proc/pid/exe</code> entry - matches this against a regex like
/usr/bin/python - back in 2022 Jakub Wilk discovered a vuln where the regex
was not anchored, so if a process was running via a attacker controlled
interpreter (<code>/home/amurray/usr/bin/python</code>) this would match and
needrestart would execute that interpreter directly as root - CVE-2022-30688</li>
<li>Hoewever, it turns out needrestart reads the processes <code>/proc/pid/exe</code>
twice - once early on when collecting info on all processes, and then a
second time to determine if it is say a Python application - but when
needrestart goes and executes this interpreter to do the PYTHONPATH lookups
etc, it uses the original value that it collected at the start of its run</li>
<li>Classic TOCTOU issue</li>
<li>So a malicious process can run with say its own malicious Python interpreter
at startup, then wait for needrestart to probe that (using say inotify to be
notified when it is accessed) and then quickly exec() the real system Python
interpreter and hence change its <code>/proc/self/exe</code> to trick needrestart -
which will then go and execute its original malicious interpreter binary</li>
</ul>
</li>
<li>Since had found issues in Python and Ruby parts of needrestart, Qualys went
looking at the Perl parts
<ul>
<li>since needrestart is written in Perl though it doesn&rsquo;t have to execute a
Perl interpreter to resolve &ldquo;imports&rdquo; etc</li>
<li>instead uses a Perl library (ScanDeps) which analyses Perl scripts directly</li>
<li>Found this module was vulnerable to a very old Perl foot-gun, Pesky Pipe
(coined in <a href="https://phrack.org/issues/55/7.html#article">1999 by rain.forest.puppy in Phrack</a>)
<ul>
<li>Perl has a feature where you can call <code>open</code> with a string that ends in a
pipe (<code>|</code>) and it will instead execute that string as a shell command</li>
<li>ScanDeps did exactly this - called <code>open</code> on any files that it finds along
the way in its analysis - and since these filenames are controlled by the
unprivileged attacker, can create a file which ends in a pipe character
(e.g. <code>/home/amurray/bin/pwned|</code>) and Perl will then just execute that
script directly</li>
</ul>
</li>
<li>Also found cases in ScanDeps where it would call <code>eval()</code> on contents from
these files as well - directly executing whatever strings found as Perl code</li>
</ul>
</li>
<li>Mark Esler on our team then liased with Qualys and got the upstream
needrestart developer involved to coordinate on writing fixes and disclosing
the issue - first to other distros via the distros mailing list and then
eventually publicly via oss-security</li>
<li>Patches to fix went through a number of revisions before being finalised</li>
<li>To fix these, a number of changes were made:
<ul>
<li>ScanDeps was fixed to use an explicit call to open() to avoid Perl executing
the argument as code and the uses of eval replaced with safer parsing</li>
<li>needrestart removed the use of ScanDeps entirely and instead replaced this
with its own regex based parsing of perl files to look for <code>use</code> directives</li>
<li>needrestart modified to not set PYTHONPATH when running the Python
interpreter and instead look inside the specified PYTHONPATH manually (to
avoid having the Python interpreter possibly load untrusted shared objects
from that path) - similarly for RUBYLIB</li>
<li>needrestart modified to use the original <code>/proc/pid/exe</code> path to match
against when looking for interpreted processes to remove the TOCTOU race</li>
</ul>
</li>
<li>Unfortunately, testing for the patches upstream wasn&rsquo;t complete and a minor
regression was introduced in the original update which caused needrestart to
misidentify processes within a container as being on the host and so would
inadvertently kill them</li>
<li>Sudhakar Verma (who handled the technical side of testing proposed patches
plus preparing and releasing the final updates) liased with upstream to help
get a fix developed and deployed as a regression fix for Ubuntu</li>
<li>Interesting to consider, the info needrestart was using comes from <code>/proc</code>
filesystem - this is a virtual filesystem managed by the kernel, representing
information about processes in userspace</li>
<li>Easy to assume the data it presents is trusted as it is populated by the
kernel - and generally file permissions are read-only for these files - so a
process can&rsquo;t just directly write to them to modify them - BUT these values
all come from the userspace process itself originally
<ul>
<li>perhaps needrestart could look at dropping privileges to those of the
process in question before doing the evaluation as well - although this is
tricky to do correctly - we&rsquo;ve seen bugs in a number of applications which
try and follow this pattern like snap-confine or apport which turn out to
cause security issues as they don&rsquo;t drop privileges completely etc</li>
</ul>
</li>
<li>Ryan Lee is looking to create an AppArmor profile for needrestart to help
confine it to hopefully limit the damage any other similar bugs may cause</li>
</ul>
<h3 id="usn-7117-1-needrestart-and-module-scandeps-vulnerabilities">[<a href="https://ubuntu.com/security/notices/USN-7117-1">USN-7117-1</a>] needrestart and Module::ScanDeps vulnerabilities</h3>
<ul>
<li>5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS), 24.10
<ul>
<li>2 medium priority CVE(s)</li>
<li>3 high priority CVE(s)</li>
</ul>
</li>
</ul>
<h3 id="usn-7117-2-needrestart-regression">[<a href="https://ubuntu.com/security/notices/USN-7117-2">USN-7117-2</a>] needrestart regression</h3>
<ul>
<li>5 CVEs addressed in Xenial ESM (16.04 ESM), Bionic ESM (18.04 ESM), Focal (20.04 LTS), Jammy (22.04 LTS), Noble (24.04 LTS), 24.10
<ul>
<li>2 medium priority CVE(s)</li>
<li>3 high priority CVE(s)</li>
</ul>
</li>
</ul>
<h2 id="get-in-contact">Get in contact</h2>
<ul>
<li><a href="mailto:security@ubuntu.com">security@ubuntu.com</a></li>
<li><a href="https://libera.chat">#ubuntu-security on the Libera.Chat IRC network</a></li>
<li><a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-hardened">ubuntu-hardened mailing list</a></li>
<li><a href="https://discourse.ubuntu.com/c/security">Security section on discourse.ubuntu.com</a></li>
<li><a href="https://fosstodon.org/@ubuntusecurity">@ubuntusecurity@fosstodon.org</a>, <a href="https://twitter.com/ubuntu_sec">@ubuntu_sec on twitter</a></li>
</ul>

<description>  This week we dive into the details of a number of local privilege escalation
  vulnerablities discovered by Qualys in the needrestart package, covering topics
  from confused deputies to the inner workings of the /proc filesystem and
  responsible disclosure as well.
  </description>


        
          This week we dive into the details of a number of local privilege escalation
  vulnerablities discovered by Qualys in the needrestart package, covering topics
  from confused deputies to the inner workings of the /proc filesystem and...
        
        

  This week we dive into the details of a number of local privilege escalation
  vulnerablities discovered by Qualys in the needrestart package, covering topics
  from confused deputies to the inner workings of the /proc filesystem and
  responsible disclosure as well.
  

Episode 242
          
          
          

<h2 id="overview">Overview</h2>
<p>This week we take a deep dive into the latest Linux malware, GoblinRAT to look
at how malware is evolving to stay stealthy and evade detection and how malware
authors are learning from modern software development along the way.</p>
<h2 id="goblinrat-linux-malware-teardown">GoblinRAT Linux Malware teardown</h2>
<ul>
<li>
<p><a href="https://rt-solar.ru/solar-4rays/blog/4861/">https://rt-solar.ru/solar-4rays/blog/4861/</a></p>
</li>
<li>
<p>Solar 4RAYS team (Cyber Threat Research Center at SOLAR - Russian
Cybersecurity firm) describes a new piece of Linux malware which they name
GoblinRAT (RAT = Remote Access Trojan) 2023 when contacted by an IT company which provides
services to (presumably) Russian government agencies - noticed system logs
being deleted off one of their servers and a utility being downloaded to steal
account passwords from a domain controller</p>
</li>
<li>
<p>Found this malware masquerading as a legitimate process which takes quite
careful steps to avoid detection - in fact most of the functionality within
the malware is devoted to hiding its presence on the target system</p>
</li>
<li>
<p>Doesn&rsquo;t include automatic persistence but instead appears to be manually
&ldquo;installed&rdquo; by the attackers with a unique name for each target where it would
be named after an existing legitimate process on the target system - similarly
even the names of its files and libraries were also unique per-system as well
to avoid detection</p>
<ul>
<li>e.g. in one case where zabbix was running, the malware named itself
<code>zabbix_agent</code> and setup a new systemd service to launch itself at boot
which looks identical to the real zabbix agent (except the real one is
<code>zabbix_agentd</code>) and then once running it edits its own command-line
arguments after startup to insert standard parameters expected by the real
<code>zabbix_agentd</code> so that on a <code>ps aux</code> or similar output it appears basically
identical to the real <code>zabbix_agentd</code></li>
<li>in another case it named itself <code>rhsmd</code> to mimic the Red Hat subscription
manager service again using systemd as the launcher, whilst for others as
<code>memcached</code> using cron to launch</li>
<li>C2 uses DDNS (Dynamic DNS) and legitimate hacked sites to hide in noise of
&ldquo;normal&rdquo; traffic - using DDNS attackers would use specifically named C2
machines per target host - in one case where it was named <code>chrony_debug</code> to
mimic the <code>chronyd</code> time synchronisation service, it would connect to C2 a
machine named <code>chronyd.tftpd.net</code> - attackers clearly went to a lot of work
to hide this in plain sight</li>
</ul>
</li>
<li>
<p>Automatically deletes itself off the system if does not get pinged by the C2
operator after a certain period of time - and when it deletes itself it <a href="https://en.wikipedia.org/wiki/Shred_(Unix)">shreds</a>
itself to reduce the chance of being detected later via disk forensics etc</p>
</li>
<li>
<p>Has 2 versions - a &ldquo;server&rdquo; and &ldquo;client&rdquo; - the server uses <a href="https://en.wikipedia.org/wiki/Port_knocking">port-knocking</a> to
watching incoming connection requests on a given network interface and then
only actually allowing a connection if the expected sequence of port numbers
was tried - this allows the controller of the malware to connect into it
without the malware actively listening on a given port and hence reduces the
chance it is detected accidentally</p>
</li>
<li>
<p>Client instead connects back to its specific C2 server</p>
</li>
<li>
<p>Logs collected by 4RAYS team appear to show the commands executed by the
malware were quite manual looking - invoking bash and then later invoking
commands like systemctl to stop and replace an existing service, where the
time lag between commands is in the order of seconds - minutes and so would
seem like these were manually typed command rather than automatically driven
by scripts</p>
</li>
<li>
<p>Malware itself is implemented in Go and includes the ability to execute single
commands as well as providing an interactive shell; also includes support for
listing / copying / moving files including with compression; also works as a
SOCKS5 proxy to allow it to proxy traffic to/from other hosts that may be
behind more restrictive firewalls etc; and as detailed above the ability to
mimic existing processes on the system to avoid detection</p>
</li>
<li>
<p>To try and frustrate reverse engineering <a href="https://github.com/unixpickle/gobfuscate">Gobfuscate</a> was used to obfuscate the
compiled code - odd choice though since this project was seemingly abandonded
3 years ago and nowadays <a href="https://github.com/burrowers/garble">garble</a> seems to be the go-to tool for this (no pun
intended)- but perhaps this is evidence of the time of the campaign since
these samples were all found back in 2020 which this project was more active&hellip;</p>
</li>
<li>
<p>Encrypts its configuration using AES-GCM and the config contains details like
the shell to invoke, kill-switch delay and secret value to use to disable it,
alternate process name to use plus the TLS certificate and keys to use when
communicating with the C2 server</p>
</li>
<li>
<p>Uses the <a href="https://github.com/hashicorp/yamux">yamux</a> Go connection multiplexing library then to multiplex the single
TLS connection to/from the C2 server</p>
</li>
<li>
<p>Can then be instructed to perform the various actions like running commands /
launching a shell / list files in a directory / reading files etc as discussed
before</p>
</li>
<li>
<p>Other interesting part is the kill switch / self-destruct functionality - if
kill switch delay is specified in the encrypted configuration malware will
automatically delete itself by invoking dd to overwrite itself with input from
/dev/urandom 8 times; once more with 0 bytes and finally then removing the
file from disk</p>
</li>
<li>
<p>Overall 4 organisations were found to have been hacked with this and in each
it was running with full admin rights - with some running for over 3 years -
and various binaries show compilation dates and golang toolchain versions
indicating this was developed since at least 2020</p>
</li>
<li>
<p>But unlike other malware that we have covered, it does not appear to be a more
widespread campaign since &ldquo;other information security companies with global
sensor networks&rdquo; couldn&rsquo;t find any similar samples in their own collections</p>
</li>
<li>
<p>No clear evidence of origin - Solar 4RAYS asking for other cybersecurity
companies to help contribute to their evidence to identify the attackers</p>
</li>
<li>
<p>Interesting to see the evolution of malware mirrors that of normal software
development - no longer using C/C++ etc but more modern languages like Go
which provide exactly the sorts of functionality you want in your malware -
systems-level programming functionality with built-in concurrency and memory
safety - also Go binaries are statically linked so no need to worry about
dependencies on the target system</p>
</li>
</ul>
<h2 id="get-in-contact">Get in contact</h2>
<ul>
<li><a href="https://libera.chat">#ubuntu-security on the Libera.Chat IRC network</a></li>
<li><a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-hardened">ubuntu-hardened mailing list</a></li>
<li><a href="https://discourse.ubuntu.com/c/security">Security section on discourse.ubuntu.com</a></li>
<li><a href="https://fosstodon.org/@ubuntusecurity">@ubuntusecurity@fosstodon.org</a>, <a href="https://twitter.com/ubuntu_sec">@ubuntu_sec on twitter</a></li>
</ul>


<description>  This week we take a deep dive into the latest Linux malware, GoblinRAT to look
  at how malware is evolving to stay stealthy and evade detection and how malware
  authors are learning from modern software development along the way.
  </description>


        
          This week we take a deep dive into the latest Linux malware, GoblinRAT to look
  at how malware is evolving to stay stealthy and evade detection and how malware
  authors are learning from modern software development along the way.
  
        
        

  This week we take a deep dive into the latest Linux malware, GoblinRAT to look
  at how malware is evolving to stay stealthy and evade detection and how malware
  authors are learning from modern software development along the way.
  

Episode 241
          
          
          

<h2 id="overview">Overview</h2>
<p>For the third and final part in our series for Cybersecurity Awareness Month,
Alex is again joined by Luci as well as Diogo Sousa to discuss future trends in
cybersecurity and the likely threats of the future.</p>
<h2 id="get-in-contact">Get in contact</h2>
<ul>
<li><a href="mailto:security@ubuntu.com">security@ubuntu.com</a></li>
<li><a href="https://libera.chat">#ubuntu-security on the Libera.Chat IRC network</a></li>
<li><a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-hardened">ubuntu-hardened mailing list</a></li>
<li><a href="https://discourse.ubuntu.com/c/security">Security section on discourse.ubuntu.com</a></li>
<li><a href="https://fosstodon.org/@ubuntusecurity">@ubuntusecurity@fosstodon.org</a>, <a href="https://twitter.com/ubuntu_sec">@ubuntu_sec on twitter</a></li>
</ul>


<description>  For the third and final part in our series for Cybersecurity Awareness Month,
  Alex is again joined by Luci as well as Diogo Sousa to discuss future trends in
  cybersecurity and the likely threats of the future.
  </description>


        
          For the third and final part in our series for Cybersecurity Awareness Month,
  Alex is again joined by Luci as well as Diogo Sousa to discuss future trends in
  cybersecurity and the likely threats of the future.
  
        
        

  For the third and final part in our series for Cybersecurity Awareness Month,
  Alex is again joined by Luci as well as Diogo Sousa to discuss future trends in
  cybersecurity and the likely threats of the future.
  

Episode 240
          
          
          

<h2 id="overview">Overview</h2>
<p>In the second part of our series for Cybersecurity Awareness Month, Luci is back
with Alex, along with Eduardo Barretto to discuss our top cybersecurity best
practices.</p>
<h2 id="get-in-contact">Get in contact</h2>
<ul>
<li><a href="mailto:security@ubuntu.com">security@ubuntu.com</a></li>
<li><a href="https://libera.chat">#ubuntu-security on the Libera.Chat IRC network</a></li>
<li><a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-hardened">ubuntu-hardened mailing list</a></li>
<li><a href="https://discourse.ubuntu.com/c/security">Security section on discourse.ubuntu.com</a></li>
<li><a href="https://fosstodon.org/@ubuntusecurity">@ubuntusecurity@fosstodon.org</a>, <a href="https://twitter.com/ubuntu_sec">@ubuntu_sec on twitter</a></li>
</ul>


<description>  In the second part of our series for Cybersecurity Awareness Month, Luci is back
  with Alex, along with Eduardo Barretto to discuss our top cybersecurity best
  practices.
  </description>


        
          In the second part of our series for Cybersecurity Awareness Month, Luci is back
  with Alex, along with Eduardo Barretto to discuss our top cybersecurity best
  practices.
  
        
        

  In the second part of our series for Cybersecurity Awareness Month, Luci is back
  with Alex, along with Eduardo Barretto to discuss our top cybersecurity best
  practices.
  

Episode 239
          
          
          

A fortnightly podcast talking about the latest developments and updates from the Ubuntu Security team, including a summary of recent security vulnerabilities and fixes as well as a discussion on some of the goings on in the wider Ubuntu Security community.

Ubuntu Security Podcast

Details

Recent Episodes