Vulmon
<!--X-Body-Begin-->
<!--X-User-Header-->
oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->
By Date
By Thread
</form>
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: backdoor in upstream xz/liblzma leading to ssh server compromise
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
From: Solar Designer <solar () openwall com>
Date: Wed, 17 Apr 2024 00:59:00 +0200
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
Hi,
This is an update on some developments in the recent 2 weeks.
OpenSSH
=======
For upstream OpenSSH, Damien Miller and others have implemented systemd
notifications without reliance on libsystemd:
Bug 2641 - Add systemd notify code to to track running server
https://bugzilla.mindrot.org/show_bug.cgi?id=2641
"Committed as 08f579231cd38 and will be in OpenSSH-9.8, due around
June/July."
In response to Andres Freund's proposal, Damien also implemented a patch
to reduce OpenSSH's attack surface:
Bug 3675 - CASignatureAlgorithms should be verified before verifying signatures
https://bugzilla.mindrot.org/show_bug.cgi?id=3675
not yet committed?
systemd
=======
Upstream systemd's libsystemd has been modified to dlopen() many of its
dependency libraries on demand:
Reduce dependencies of libsystemd #32028
https://github.com/systemd/systemd/issues/32028
The issue above is fixed by pull requests "gcrypt: dlopenify for
libsystemd #32019", "Dynamically load compression libraries #31550",
"man: document that using sd_journal APIs might cause dlopen to happen
and add self-contained notify protocol example #32030", and other
related fix-ups.
xz backdoor analysis
====================
More findings were made about the backdoor's functionality, notably as
published on April 6 by blasty, who discovered that besides triggering
system() the backdoor also allows interactive sessions:
https://twitter.com/bl4sty/status/1776691497506623562
the xz sshd backdoor rabbithole goes quite a bit deeper. I was just able
to trigger some harder to reach functionality of the backdoor. there's
still more to explore.. 1/n
Image
it requires sending a properly crafted command to the RSA_public_decrypt
hook, which will then install another for the `mm_answer_keyallowed`
sshd function. subsequently you offer N more fake ssh-rsa pubkeys which
are crafted in a special way to chunk together .. 2/n
a "magic buffer" which contains more backdoor commands, this buffer also
has two additional ed448 signatures. which like the ones for the
RSA_public_decrypt portion of the backdoor are salted with the SHA256
digest of the hostkey
the final signature also takes into account the session_id (0x20 bytes)
that is derived during the initial key exchange (KEX) for the SSH
session. my current PoC implementation uses a heavily monkey patched
paramiko (ssh client) library to achieve this
currently I'm just triggering command 0x03 in this part of the code,
which allows for a basic RCE through system() again. (also lets you set
uid/gid). but there's more code that needs to be understood. it looks
like a full auth bypass (interactive session) is possible!
(that conclusion is based on the fact that one of the
mm_answer_keyallowed backdoor commands also hooks mm_answer_keyverify,
eventually)
whoever designed this stuff had to take a deep dive into openSSH(d)
internals (and so did I for the past couple of days, oof) .. hats off,
once again :)
auth bypass confirmed!
INFO:paramiko.transport:Authentication (password) successful!
mm_keyallowed_backdoor cmd 1 allows to override the response for
mm_answer_authpassword with a custom one. if you set it to { u32(9),
u8(13), u32(1), u32(0) } you can login with any pass
blasty also implemented a "simple SSH Agent that implements some of the
XZ sshd backdoor functionality":
https://github.com/blasty/JiaTansSSHAgent
On Sun, Mar 31, 2024 at 10:25:02PM +0200, Solar Designer wrote:
There's further analysis of the binary payload here:
https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
I've attached the gist .md file above (as of "Revisions 52") to this
message, but it's ongoing analysis as seen in the comments.
Updates of smx-smx's gist above have stopped at revision 60, which I'm
attaching here for archival. Not a lot was added since revision 52.
smx-smx also maintains xzre "that is linked against the malicious object
file in order to instrument and call into the malware code, particularly
the x64 disassembler":
https://github.com/smx-smx/xzre
and yes, there's a specialized disassembler inside the backdoor code.
The friends at Binarly have produced a later but very detailed analysis,
which I'm also attaching the main .md file of:
https://github.com/binarly-io/binary-risk-intelligence/tree/master/xz-backdoor
Other related repos with tools include:
xzbot "notes, honeypot, and exploit demo for the xz backdoor (CVE-2024-3094)"
https://github.com/amlweems/xzbot
xz-min "Minimal setup to trigger the xz backdoor"
https://github.com/felipec/xz-min
Timeline
========
In an otherwise inappropriate rejected posting, Steffen Nurpmeso wrote:
Russ Cox had a writeup on this https://research.swtch.com/xz-timeline
which is a good presentation of the attack timeline, with references to
sources and analyses by others.
(The beginning of this oss-security thread until April 1st inclusive
went through in its entirety - nothing rejected - but I did reject a few
postings on April 2nd and on.)
OpenJS Foundation "Failed Credible Takeover Attempt"
====================================================
On April 15, the OpenJS and OpenSSF foundations released the following:
https://openjsf.org/blog/openssf-openjs-alert-social-engineering-takeovers
https://openssf.org/blog/2024/04/15/open-source-security-openssf-and-openjs-foundations-issue-alert-for-social-engineering-takeovers-of-open-source-projects/
I'll quote an excerpt:
The OpenJS Foundation Cross Project Council received a suspicious series
of emails with similar messages, bearing different names and overlapping
GitHub-associated emails. These emails implored OpenJS to take action to
update one of its popular JavaScript projects to "address any critical
vulnerabilities," yet cited no specifics. The email author(s) wanted
OpenJS to designate them as a new maintainer of the project despite
having little prior involvement. This approach bears strong resemblance
to the manner in which "Jia Tan" positioned themselves in the XZ/liblzma
backdoor.
None of these individuals have been given privileged access to the
OpenJS-hosted project. The project has security policies in place,
including those outlined by the Foundation's security working group.
The OpenJS team also recognized a similar suspicious pattern in two
other popular JavaScript projects not hosted by its Foundation, and
immediately flagged the potential security concerns to respective OpenJS
leaders, and the Cybersecurity and Infrastructure Security Agency (CISA)
within the United States Department of Homeland Security (DHS).
Alexander
Attachment:
smx-smx-xz-backdoor_analysis.md
Description:
Attachment:
binarly-xz-backdoor-readme.md
Description:
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
By Date
By Thread
Current thread:
Re: backdoor in upstream xz/liblzma leading to ssh server compromise Jakub Wilk (Apr 01)
<Possible follow-ups>
Re: Re: backdoor in upstream xz/liblzma leading to ssh server compromise Jakub Wilk (Apr 12)
Re: backdoor in upstream xz/liblzma leading to ssh server compromise Solar Designer (Apr 16)
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->