Linuxfx: Revenge of the Skids

Introduction

This post is an update to the previous post on Linuxfx. Please read that first if you haven’t done so.

Aftermath

Several hours after DistroTube uploaded a video on the previous post, the Linuxfx “developers” revoked the leaked database credentials after people started griefing the database. However, they did not properly fix the underlying issue, leaving the database wide open for intrusion.

More dynamic analysis

I downloaded the latest Linuxfx installation media and threw it in a libvirt VM just like last time. I noticed a new string in the GUI activation client binary:

pkexec killall -9 sudo

It seems like the skids actually modified the activation client to try and protect itself against dynamic analysis. (Un)fortunately this one in particular can be bypassed by using pkexec for elevation instead of sudo.

To work around any potential self protection, I copied /usr/bin/bpftrace to /tmp/systemd and ran a modified version of the command in the last post:

pkexec /tmp/systemd -e 'uprobe:/usr/lib/x86_64-linux-gnu/libmysqlclient.so.21:mysql_real_connect { printf("host=%s user=%s password=%s database=%s port=%d\n", str(arg1), str(arg2), str(arg3), str(arg4), arg5); }'

This gives us the following:

host=181.215.242.77 user=fxuser password=99D28/gQxU%WY database=newbase port=19708

Connecting to the database shows that the credentials are valid.

Even more dynamic analysis

I’m still interested in finding out exactly what the program executes, what files does the program opens, etc.

Installing bpfcc-tools and copying /usr/bin/execsnoop-bpfcc to /tmp/systemd and running:

pkexec /tmp/systemd

and then opening the activation client gives us the following interesting output:

The activation program seems to check for the presence of sudo, stap (the SystemTap system tracing utility), and anything containing bp, which will catch bpftrace and *-bpfcc tools. When it detects such programs, the following notification is shown:

The program also uses curl to download data from the following URLs: http://www.linuxfx.org/linuxfx/x86/11.1/.http and http://www.linuxfx.org/linuxfx/x86/11.1/.https. The first URL contains the database type, port, host, database and username. The second URL contains the database password:

$ curl http://www.linuxfx.org/linuxfx/x86/11.1/.http
mysql
19708
181.215.242.77
newbase
fxuser
$ curl http://www.linuxfx.org/linuxfx/x86/11.1/.https
99D28/gQxU%WY

This means that the activation program doesn’t store any credentials in its binary, but it’s stored on unauthenticated HTTP endpoints that anybody can access.

Repeating the same steps for opensnoop-bpfcc and running it with the -n gbr3 argument shows that the program reads the hardware ID from /boot/.grubkey and writes the key to /opt/Linuxfx/wxdesktop/.key.

Q.E.D.

Conclusion

Not only did the skids from Linuxfx Software fail to learn anything, they even tried to further rely on “security through obscurity” by attempting to prevent dynamic analysis of the system, which failed spectacularly as you have seen above.

As proof for the database compromise, the following key can be used to activate virtually infinite Linuxfx machines:

00-4200-9999-999999999999