I implemented Ken Thompson’s Reflections on Trusting Trust (1984 Turing Award Lecture) compiler #backdoor for the GNU Compiler Collection (GCC). The backdoor maintains persistence by re-injecting itself to any new versions of the compiler built. The secondary payload modifies a test application by adding a backdoor password to allow authentication bypass:

$ cat testapp.c
#include <string.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
if (argc == 2 && !strcmp(argv[1], "secret"))
{
printf("access granted!\n");
return EXIT_SUCCESS;
}
else
{
printf("access denied!\n");
return EXIT_FAILURE;
}
}
$ gcc -Wall -O2 -o testapp.c -o testapp
$ ./testapp kensentme
access granted!
$

I spent most time (around two hours) writing the generalized tooling that produces the final quine version of the malicious payload. Now that this is done, the actual code can be adjusted trivially to exploit more target code without any need to adjust the self-reproducing section of the code. This method of exploitation could be extended to target various binaries: SSH Server, Linux Kernel, Setuid binaries and similar. While itself written in C, the secondary payloads can target any programming languages supported by GCC.

It should be noted that GCC build checks for malicious compiler changes such as this. This check can – of course – also be bypassed. However, most serious projects have measures in place to avoid hacks of this nature.

Some links:
- Ken Thompson's "Reflections on Trusting Trust" paper: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
- David A. Wheeler: "Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers" https://dwheeler.com/trusting-trust/

#hacking #exploitdevelopment #kenthompson #infosec #cybersecurity @vegard

Put yourself in Jia Tan's shoes, the malicious contributor to the xz backdoor...

It's been, what, two... three?... years since you started this campaign. You've had the entire support of your team and of your chain of command.

Your coders created a complex and sublime backdoor. A secure! backdoor that only you and your team could connect to. Heck it can even be deleted remotely. This is clean code. A responsible hack that doesn't open up the backdoor for others to hijack.

You spend years on your long con - your social engineering skills are at the top of the game. You've ingratiated yourself painstakingly into multiple teams. Finally it all pays off and you're ready to go!

You succeed multiple times in getting your backdoor inserted in all the major Linux distributions!!! Now its just a matter of weeks before it makes it to production and stable releases!

This is the culmination of years of labor and planning and of a massive team and budget.

You did good.

This will get you promoted. Esteemed by your colleagues and leadership alike. Your spouse and kids will understsnd why you haven't been at home lately and why you've spent all those late nights at the office.

It's finally going to pay off.

But what's this?! Some rando poking around in their box running a pre-release unstable version of linux has found everything?!?! It's all being ripped down?! And on a Friday before a western holiday weekend?!?!

Fuck. Fuck. FUCK!!!

Three years for nothing!!! My wife is going to leave me! I missed my kid's recital for this!!! They'll hate me because I told them it was worth it. Daddy will be able to play with you again once Daddy finishes this last bit of work. But it was all for nothing!!!

Leadership took a big risk on me and my team but I kept assuring them it would pay off!

It would be one thing if another nation state found it and stopped it. But one random dude poking his nose where it shouldn't belong?! Ohhh fuck, I'm going to be fired. We're going to lose our budget. My team is going to be fired. I've let down everyone that ever believed in me and supported me and relied on me!

Oh fuck!!!

#xz #backdoor #xzBackDoor #cve #cve20243094 #infosec #hacking #FOSS

I think a LOT of people are missing the fact that we got LUCKY with this malicious backdoor.

The backdoor was created by an Insider Threat - by a developer / maintainer of various linux packages. The backdoor was apparently pushed back on March 8th (I believe) and MADE IT PAST all QA checks.

Let me state that again. Any quality assurance, security checks, etc., failed to catch this.

This was so far upstream, it had already gotten into the major Linux distributions. It made it into Debian pre-release, Fedora rolling, OpenSUSE rolling, Kali rolling, etc.

This is an example of Supply Chain Security that CISOs love to talk and freak out about. This is an example of an Insider Threat that is the boogey man of corporate infosec.

A couple more weeks, and it would have been in many major distributions without any of us knowing about it.

The ONLY reason we know about it is because @AndresFreundTec got curious about login issues and some benchmarking checks that had nothing to do with security and ran the issue down and stumbled upon a nasty mess that was trying to remain hidden.

It was luck.

That's it. We got lucky this time.

So this begs the question. Did the malicious insider backdoor anything else? Are they working with anyone else who might have access to other upstream packages? If the QA checks failed to find this specific backdoor by this specific malicious actor, what other intentional backdoors have they missed?

And before anyone goes and blames Linux (as a platform or as a concept), if this had happened (if it HAS happened!!!) in Windows, Apple, iOS, etc.... we would not (or will not) know about it. It was only because all these systems are open source that Andres was able to go back and look through the code himself.

Massive props and kudos and all the thank yours to Andres, those who helped him, to all the Linux teams jumping on this to fix it, and to all the folks on high alert just before this Easter weekend.

I imagine (hope) that once this gets cleaned up, there will be many fruitful discussions around why this passed all checks and what can be changed to prevent it from happening again.

(I also hope they run down any and all packages this person had the signing key for....)

#infosec #hacking #cve #cve20243094 #linux #FOSS

Das ist so absurd. Man weiß wirklich nicht, ob man lachen oder weinen soll. phpMyAdmin ist offenbar ein »gefährliches Hackertool« im Sinne des Hackerparagrafen 202a StGB. Wenn der Gesetzgeber das JETZT nicht ändert, dann war es das mit der Responsible Disclosure. Wenn man jetzt noch dafür belangt wird, überlegt man sich zweimal, ob man die Daten nicht gleich gewinnbringend verkauft... 🤦‍♂️

https://www.golem.de/news/modern-solution-it-experte-wegen-nutzung-einer-zugriffssoftware-verurteilt-2401-181296.html

#hacker #hacking #responsibledisclosure #gesetz #hackerparagraf #hackerparaph