TOX PROJECT

INFRASTRUCTURE

Security review

Prepared for :
zero-one, chief
would you mind writing a short report
at the TOX Project

Prepared by :
tux3 <barrdetwix@gmail.com>, official
backdoor implementer for the qTox Project
1 Scope

The report is only concerned with the security implications

of a malicious actor achieving arbitrary code execution in the
context of a Jenkins slave of the Tox Project's continous
integration (CI) infrastructure.
This level of control can be achieved in various ways, but this
document will focus on the case study of an attacker abusing
access to a Tox Project Jenkins account.

The Tox Project's master Jenkins installation (hereafter

refered to as Jenkins) has fourty-three (43) users with varying
levels of permissions and access to Tox Project resources.
Those users run code on the following three (3) jenkins
slaves through the mean of Jenkins jobs :

linux-x86.slave.tox.chat
linux-x86-64.slave.tox.chat
linux-arm7.slave.tox.chat

Our example attacker will be assumed to have control of one

Jenkins account, with permissions to either create new builds
or edit an existing build's configuration.

The attacker will be assumed to be a lazy sleep deprived

amateur with very little perseverance or time to spare, and as
such this report only explores the obvious immediate ways in
which such an attacker could abuse its access to the system.
The consequences of an attacker with a bare modicum of
motivation or time on its hand have not been explored and
may only be mentionned in passing.
2 Immediate Exploitation

The assessment started from the point of view of an attacker

with configuration access to a Jenkins job.
This level of access is equivalent to the ability of running
arbitrary code in the content of the jenkins user on the Tox
Project's three (3) Jenkins slave machines.
Initial access to the slaves was established via a simple
reverse-bind shell using a netcat-traditional binary uploaded
through the Jenkins job configuration interface.
This precarious netcat shell can be turned into a minimal
interactive bash shell by the attacker with a minimal amout
of fumbling using the following Pyhton command :

python -c 'import pty; pty.spawn("/bin/bash")'

Finally, the access vector can be migrated from the context

of a running Jenkins job to a SSH session by editing the local
jenkins user's .ssh/authorized_keys file.
At this point the attacker has trivially leveraged Jenkins job
access to gain SSH access to the three Jenkins slaves, and
the initial Jenkins job can now be deleted.
The steps up to this point can be completed in a matter of
minutes, leaving a short window where the attacker's
compromised Jenkins job is publicly visible on the web UI.

Access to the Jenkins master was not achieved through this

vector, the combination of Jenkins plugins installed and lack
of executors on the Jenkins master did not allow for any
obvious way of access.
3 Information Gathering

Access to the Jenkins slaves immediately translates into read

and write access into all Jenkins build workspaces, and any
resources Jenkins jobs may need access to.
A rudimentary search for keks and further exploitation
vectors found the target systems adequately configured and
fully patched with unnatended-upgrades installed, and all the
information gathering was done strictly in the content of the
jenkins user without any sophisticated attack of any kind.

One particularly fruitful resource that allowed pivot into two

(2) new systems is the .bash_history of the jenkins user,
which seems to have not been erased since the slaves were
first setup. This file is one of the first places any attacker with
half a brain cell will check, leaving any credentials in it is
tremendously foolish. The history files have been cleared by
yours truly prior to the writing of this report.
The following two history entries were of particular interest :

$ sftp -P2299 pkg.tox.chat

$ ssh jenkins@antox.me -p2222

An attacker may now steal the local jenkins user's private ssh
key to mainting permanent read-write access to the Tox
package repositories from anywhere in the world :

-----BEGIN RSA PRIVATE KEY-----

MIIEowIBAAKCAQEAxzk0UWhu8AyUVqTrpbt+lNvXC7zGBIWkvnUiB
[]
rxymfeLWD3cmqP3V835A8hEvx6wOYJ3fez3L6H1Xy49YJtW4mNHj
-----END RSA PRIVATE KEY-----
The consequences of gaining access to antox.me will be
explored in section 4.

At this point an attacker has a variety of ways to compromise

all of the Tox project's builds and packages, but all of these
largely require maintaining connections to jenkins slaves and
periodically running arbitray code which, one can onlly hope,
the Tox infrastructure mainteners would be bound to notice
eventually.
Instead, access to the build workspaces means that stealing
secret and signing keys for Jenkins builds is now possible,
this would allow attackers to compile their own builds at
home, and still have them signed with the Tox Project's keys.

One such interesting key is the Antox keystore key, which

allows to sign and publish Antox release to the Android
market. This file can be found on the Jenkins slaves in
/opt/antox_release.keystore and trivially exfiltrated .
Once again, the presence of this file was revealed by the
.bash_history file, saving the attacker some time.
4 Lol, subliun

During the engagment SSH access to antox.me was

established under the jenkins user.

This machine obviously constitutes extremely critical

infrastructure and hosts information invaluable to the Tox
Project's continued existence, as evidenced by the data :

jenkins@Toxme:~$ ls -la /home/vinal/site/

total 7240
drwxrwxr-x 2 vinal vinal 4096 Aug 21 08:48 .
drwxr-xr-x 3 vinal vinal 4096 Aug 21 15:04 ..
-rw-rw-r-- 1 vinal vinal 37038 Aug 21 07:00 image.png
-rw-rw-r-- 1 vinal vinal 744 Aug 21 08:53 index.html
-rw-rw-r-- 1 vinal vinal 1812 Aug 21 08:47 nasa.gifv
-rw-rw-r-- 1 vinal vinal 1659041 Aug 21 08:21 nicememe.gif
-rw-rw-r-- 1 vinal vinal 5689573 Aug 21 08:38 nicememe.mp3

The file system permissions being remarkably lenient, the

jenkins user on this system could access various important
files in all four (4) users' homes.

In particular, the certificates for antox.me and toxme.io

as well as the live code and database of toxme.io were
world readable and partially word-writable, which would be
hilarious if not for the fact that those certs may have been
accessed by any Tox client writer, library maintener, and 43
jenkins user, and should now be considered compromised.
I hope those were cheap

Open-source all the way

5 TL;DR Executive Summary

The following level of access was obtained:

- Permanent SSH access to three (3) jenkins build machines,

- Permanent SFTP access to the package repository,
- Permanent SSH access to antox.me and toxme.io,
- Compromise of all Tox software releases and packages,
- Theft of antox.me and toxme.io certificates,
- Theft of the toxme.io source and database,
- Theft of the Antox signing and market publishing key,
- Info of orange owning francis@xeon.pw . Hi francis.

The following persons may have privileges sufficient to

reproduce the steps outlined in this document, by virtue of
running code in the context of the jenkins user :

- The fourty-three (43) registered Tox Jenkins users,

- All Tox client and library developpers with a Jenkins build,
- Mainteners of all external libraries used by Jenkins builds
6 Recommendations Summary

Steps should be taken to ensure that all fourty-three (43)

Jenkins user accounts truly require this level of access.

External library build scripts should not have access to

internal Tox Project files, and for example qTox scripts should
not have access to the workspaces of Antox jobs.
Ideally, access for each Jenkins role should be strictly
compartimentalized, which dedicated Jenkins slaves in
secure jails for different projects, and fine-grained
permissions for what slaves each project can build on.
However, this is a significantly more complicated setup, and
may be seen as superfluous as long as Jenkins users are
trusted.

But this leaves the problem of external libraries running

arbitrary code as the jenkins user during compilation.
At the bare minimum, we recommand to not just shove the
Antox keystore file in /opt/ readable by all Jenkins jobs,
and not granting external library build scripts the full
permissions of the jenkins user, such as write access to
~/.ssh/authorized_keys .

And for the love of Stallman, subliun please run :

sudo chmod o-rwx /home/ -R