You can't really hack a bios like you used to be able to, because the bios has to be digitally signed now and your mainboard won't boot if the signature doesn't match or if it isn't signed by a recognized authority.
Theoretically it would be possible to sign a bad bios with a legit key if a hacker had access to one, but that is exceedingly unlikely.
You can't really hack a bios like you used to be able to, because the bios has to be digitally signed now and your mainboard won't boot if the signature doesn't match or if it isn't signed by a recognized authority.
Theoretically it would be possible to sign a bad bios with a legit key if a hacker had access to one, but that is exceedingly unlikely.
Signed bios updates have made things better, but they are not completely secure. A bad actor getting their hands on a legitimate signing key is not the only avenue of compromise. And bios signing keys have been leaked before, which makes any bios using them that is behind on updates vulnerable. Further, bios updates are still dependent on all the supporting hardware and code to be free of bugs and security holes and for it all to be configured 100% correctly, if the vendor bothers to do it at all, signed code or not.
Just remember that half the people you meet are below average intelligence.
+4
Options
TetraNitroCubaneThe DjinneratorAt the bottom of a bottleRegistered Userregular
This is much more likely to be respawn infra compromised as the same hacker has hacked ranked lobbies to have a ton of zombie bots chasing certain pros.
Not to say other exploits aren't also in play, but I wouldn't point at EAC being the source. I hate the kernel level stuff too, but the reality is there's no other methods to combat cheaters besides an army of humans reviewing vods who may get it wrong
0
Options
TetraNitroCubaneThe DjinneratorAt the bottom of a bottleRegistered Userregular
This is much more likely to be respawn infra compromised as the same hacker has hacked ranked lobbies to have a ton of zombie bots chasing certain pros.
Not to say other exploits aren't also in play, but I wouldn't point at EAC being the source. I hate the kernel level stuff too, but the reality is there's no other methods to combat cheaters besides an army of humans reviewing vods who may get it wrong
I mean, we're seeing evidence it really isn't effective at this at all?
This is much more likely to be respawn infra compromised as the same hacker has hacked ranked lobbies to have a ton of zombie bots chasing certain pros.
Not to say other exploits aren't also in play, but I wouldn't point at EAC being the source. I hate the kernel level stuff too, but the reality is there's no other methods to combat cheaters besides an army of humans reviewing vods who may get it wrong
I mean, we're seeing evidence it really isn't effective at this at all?
all EAC actually does is validate file integrity, if I remember correctly. Valorant is one of the most aggressive and as far as I know doesn't have a serious cheating scene.
I suspect this has been blown out of proportion. So far there has been no evidence to indicate EAC has been compromised. Other vectors like source engine exploits or just good old fashioned social engineering seem more likely. This isn't to say it's impossible, but I'm going to need more evidence than a speculative 'maybe' tweet from a volunteer group. Everything after that seems like hysteria, especially as people will see what they want to see.
I suspect this has been blown out of proportion. So far there has been no evidence to indicate EAC has been compromised. Other vectors like source engine exploits or just good old fashioned social engineering seem more likely. This isn't to say it's impossible, but I'm going to need more evidence than a speculative 'maybe' tweet from a volunteer group. Everything after that seems like hysteria, especially as people will see what they want to see.
There's a new Thor video that I'm halfway through.
The issue seems to be that there's at least two different exploits being shown.
The first one could very well be that these streamers were fished and compromised individually.
But the same hacker seems to have the ability to do a bunch of server side shit like give everyone free packs (money stuff) and spawn bots in the middle of the match, as well as get into games with said streamers at will (essentially overriding matchmaking.)
And they have been doing this for at least several weeks if not months already.
( < . . .
+4
Options
TetraNitroCubaneThe DjinneratorAt the bottom of a bottleRegistered Userregular
Telegram is offering a new way to earn a premium subscription free of charge: all you have to do is volunteer your phone number to relay one-time passwords (OTP) to other users. This, in fact, sounds like an awful idea — particularly for a messaging service based around privacy.
X user AssembleDebug spotted details about the new program on the English-language version of a popular Russian-language Telegram information channel. Sure enough, there’s a section in Telegram’s terms of service outlining the new “Peer-to-Peer Login” or P2PL program, which is currently only offered on Android and in certain (unspecified) locations. By opting in to the program, you agree to let Telegram use your phone number to send up to 150 texts with OTPs to other users logging in to their accounts. Every month your number is used to send a minimum number of OTPs, you’ll get a gift code for a one-month premium subscription.
I can think of at least three different ways this is ABSOLUTELY A HORRIBLE IDEA. But serious... What????
What's the supposed use case for that? Beyond providing a way to obfuscate/launder criminal activity
I’m sure saving money by not having to pay for an SMS contract (which not coincidentally makes it harder to find out who’s actually running the show) wasn’t a consideration. Nor was the fact that they would, if they set the mystery threshold correctly, never actually have to pay out their “free premium subscription” offer - the higher the percentage of the user population that signs up to be auth bots the less likely anyone is to meet any threshold.
Plus I’m sure there’s no chance someone could set up a SMS triggered bomb on the service and accidentally implicate some random person from across the continent….
TetraNitroCubaneThe DjinneratorAt the bottom of a bottleRegistered Userregular
edited March 29
This one's for the Linux folks. I admit I'm not fully up to speed on this one, so I'll let the experts do the talking. But you can find it under CVR-2024-3094
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.
Notably, while the NIST have not yet rated this vulnerability, Red Hat rate it a 10.0 on severity.
Hopefully this one was caught before it could make it into the wild. Seems like it may only be in very, very current versions? But regardless I presume this one is going to be on the radar of a huge number of sysadmins.
Notably, this one is hair-raising specifically because it seems that a backdoor was snuck into an otherwise trustworthy repository. I could be wrong, but this looks like a supply-chain attack, and those have the potential to get nasty.
TetraNitroCubane on
0
Options
augustwhere you come from is goneRegistered Userregular
Wonder if that was done by a nation/state/mafia organization, or if it’s just one crazy person who fancies themselves a Bond villain.
0
Options
TetraNitroCubaneThe DjinneratorAt the bottom of a bottleRegistered Userregular
From the rumblings that abound, likely a crazy person doing the villain thing - And the only reason I say that is because apparently what tipped someone off to discover this thing, was that it's so poorly coded it visibly, noticeably impacts system performance in a way that's hard to miss. I'd imagine a state actor would make it a bit smoother.
Also, for anyone else interested in more, there's now a reasonable FAQ about the vulnerability that explains it all better than I could.
On March 29th, 2024, a backdoor was discovered in xz-utils, a suite of software that gives developers lossless compression. This package is commonly used for compressing release tarballs, software packages, kernel images, and initramfs images. It is very widely distributed, statistically your average Linux or macOS system will have it installed for convenience.
This backdoor is very indirect and only shows up when a few known specific criteria are met. Others may be yet discovered! However, this backdoor is at least triggerable by remote unprivileged systems connecting to public SSH ports. This has been seen in the wild where it gets activated by connections - resulting in performance issues, but we do not know yet what is required to bypass authentication (etc) with it.
We're reasonably sure the following things need to be true for your system to be vulnerable:
You need to be running a distro that uses glibc (for IFUNC)
You need to have versions 5.6.0 or 5.6.1 of xz or liblzma installed (xz-utils provides the library liblzma) - likely only true if running a rolling-release distro and updating religiously.
We know that the combination of systemd and patched openssh are vulnerable but pending further analysis of the payload, we cannot be certain that other configurations aren't.
While not scaremongering, it is important to be clear that at this stage, we got lucky, and there may well be other effects of the infected liblzma.
If you're running a publicly accessible sshd, then you are - as a rule of thumb for those not wanting to read the rest here - likely vulnerable.
Wonder if that was done by a nation/state/mafia organization, or if it’s just one crazy person who fancies themselves a Bond villain.
The latter almost certainly.
Elsewhere people are whipping themselves into a frenzy about it definitely being a nation-state, which mostly tells you those people haven't really thought about it.
Nation-states don't have teams of lone wolf hackers. If you're doing offensive cybersecurity for like, the NSA then you're just another government employee with a mildly interesting to 9-5. You would have reports, managers, taskings and requests and internal funding assignments for different efforts.
Which amongst other things means, given the pretty poor and untested nature of the exploit, that either it's a really poorly run team, or much more likely, wasn't really tested much at all. Because if the NSA is writing an exploit, then they're going to run that out on a server farm and build infrastructure, QA it, the whole lot - just like any other software release process.
Basically this seems like the software equivalent of a mass-shooter.
The community aren't wanting to make accusations, but that package only has 2 maintainers. The original one that's been doing it for 15 years and one that's been doing it for 1.5. If it wasn't one of those two, then it would have been either one of their accounts was compromised or they were tricked (or bribed/threatened) into commiting the malicious code changes written and submitted by someone else.
SiliconStew on
Just remember that half the people you meet are below average intelligence.
People have been looking through commit logs and mailing lists and this definitely has markers of a coordinated op. There's multiple other accounts applying pressure on the original maintainer to bring in someone and the malicious account was introduced by one of these pressuring accounts
+1
Options
TetraNitroCubaneThe DjinneratorAt the bottom of a bottleRegistered Userregular
People have been looking through commit logs and mailing lists and this definitely has markers of a coordinated op. There's multiple other accounts applying pressure on the original maintainer to bring in someone and the malicious account was introduced by one of these pressuring accounts
Yeah, apparently whoever is behind this had a bunch of sockpuppets they were using to coordinate disinformation.
The biggest narrative they were pushing was that the older versions of libazma were crashing. And thus every distro should be updating to the latest version of liblzma right now.
The more we learn about this, the more it feels like a real bullet dodged.
0
Options
Inquisitor772 x Penny Arcade Fight Club ChampionA fixed point in space and timeRegistered Userregular
Really, this should be a giant wake-up call that no one should expect open-source to be a silver bullet. It also points to how ludicrous it is to assume that one or a handful of people should be expected to maintain important libraries for absolutely nothing.
People have been looking through commit logs and mailing lists and this definitely has markers of a coordinated op. There's multiple other accounts applying pressure on the original maintainer to bring in someone and the malicious account was introduced by one of these pressuring accounts
Again: people underestimate what one dedicated crazy person can do.
"Multiple accounts" is a pretty low bar to clear when you have people running literally hundreds of Twitter it's at times.
Like, how much history did these accounts have. How long does it take to fab up a GitHub profile or get an email? Everyone loves talking about this stuff as though any of these things are hard for one guy to do over a couple of months.
The community aren't wanting to make accusations, but that package only has 2 maintainers. The original one that's been doing it for 15 years and one that's been doing it for 1.5. If it wasn't one of those two, then it would have been either one of their accounts was compromised or they were tricked (or bribed/threatened) into commiting the malicious code changes written and submitted by someone else.
Is basically a binary file sneaked in as a "test case"*, that is buried in a dependency, that rewrites the code during compilation (so none of this is visible on source code at all) and makes it so a call to a particular function calls a different function with the backdoor. And Freund only noticed because the inserted code was hogging a lot of CPU time for apparently no reason.
*Eat shit, developers that said "but is code for testing, it doesn't matter". If it touches production, it absolutely fucking matters.
The Verge article talks about the social engineering aspect of sleazily faking concern to insert their own man into XZ:
But really, the best (only?) place you can really get away with this is a compression library. You need invalid binary files to hide in and few projects have any need for those hanging around. Combine with a completely unreadable build system (configure makefiles) and you can hide pretty well. Without those, you've gotta get way more clever
But really, the best (only?) place you can really get away with this is a compression library. You need invalid binary files to hide in and few projects have any need for those hanging around. Combine with a completely unreadable build system (configure makefiles) and you can hide pretty well. Without those, you've gotta get way more clever
I'd be very happy if this prompted a movement to burn autotools to the ground though.
0
Options
OrcaAlso known as EspressosaurusWrexRegistered Userregular
Palo Alto - Putting The Protecc In GlobalProtect (CVE-2024-3400)
Welcome to April 2024, again. We’re back, again.
Over the weekend, we were all greeted by now-familiar news—a nation-state was exploiting a “sophisticated” vulnerability for full compromise in yet another enterprise-grade SSLVPN device.
We’ve seen all the commentary around the certification process of these devices for certain .GOVs - we’re not here to comment on that, but sounds humorous.
CVE-2024-3400
We start with very little, and as in most cases are armed with a minimal CVE description:
A command injection vulnerability in the GlobalProtect feature of Palo Alto Networks
PAN-OS software for specific PAN-OS versions and distinct feature configurations may
enable an unauthenticated attacker to execute arbitrary code with root privileges on
the firewall.
Cloud NGFW, Panorama appliances, and Prisma Access are not impacted by
this vulnerability.
What is omitted here is the pre-requisite that telemetry must be enabled to achieve command injection with this vulnerability. From Palo Alto themselves:
This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0, and PAN-OS 11.1 firewalls
configured with GlobalProtect gateway or GlobalProtect portal (or both) and device
telemetry enabled.
The mention of ‘GlobalProtect’ is pivotal here - this is Palo Alto’s SSLVPN implementation, and finally, my kneejerk reaction to turn off all telemetry on everything I own is validated! A real vuln that depends on device telemetry!
Palo Alto - Putting The Protecc In GlobalProtect (CVE-2024-3400)
Welcome to April 2024, again. We’re back, again.
Over the weekend, we were all greeted by now-familiar news—a nation-state was exploiting a “sophisticated” vulnerability for full compromise in yet another enterprise-grade SSLVPN device.
We’ve seen all the commentary around the certification process of these devices for certain .GOVs - we’re not here to comment on that, but sounds humorous.
CVE-2024-3400
We start with very little, and as in most cases are armed with a minimal CVE description:
A command injection vulnerability in the GlobalProtect feature of Palo Alto Networks
PAN-OS software for specific PAN-OS versions and distinct feature configurations may
enable an unauthenticated attacker to execute arbitrary code with root privileges on
the firewall.
Cloud NGFW, Panorama appliances, and Prisma Access are not impacted by
this vulnerability.
What is omitted here is the pre-requisite that telemetry must be enabled to achieve command injection with this vulnerability. From Palo Alto themselves:
This issue is applicable only to PAN-OS 10.2, PAN-OS 11.0, and PAN-OS 11.1 firewalls
configured with GlobalProtect gateway or GlobalProtect portal (or both) and device
telemetry enabled.
The mention of ‘GlobalProtect’ is pivotal here - this is Palo Alto’s SSLVPN implementation, and finally, my kneejerk reaction to turn off all telemetry on everything I own is validated! A real vuln that depends on device telemetry!
fucking
lol
Yep this was fun to deal with. Our hosting provider and PA really didn't treat this with the respect it needed and it revealed a lot of weaknesses in how our hosting provider does certain things. Anyway we spend half the day Thursday and literally the entire day yesterday on calls getting this straightened out. And yes, it looks like we were hit, but thankfully they never got around to actually doing anything with the data they got, never logged in and never accessed anything, so we were able to get things changed and and the patch to prevent this applied. Biggest shit show I've been involved in since Log4j
Mitre got popped by the Ivanti 0-days back in January. They patched and replaced but missed the actors lateral movement to their VMWare infrastructure and didn't detect them until this week.
...An attacker, while commenting on any GitHub commit/PR, can "attach" a file that gets assigned a URL slug containing the name of the repo where the comment was made. Even if the comment is never actually posted or later deleted by the attacker, the link to the file remains live!
And, the repo owner (Microsoft in this case) would have no knowledge of or control over such files.
Threat actors have been abusing this flaw to distribute malicious executables under the false pretense that these are coming from credible organizations' code repos.
Also GitHub getting in on some anonymous malware hosting
Posts
Theoretically it would be possible to sign a bad bios with a legit key if a hacker had access to one, but that is exceedingly unlikely.
Signed bios updates have made things better, but they are not completely secure. A bad actor getting their hands on a legitimate signing key is not the only avenue of compromise. And bios signing keys have been leaked before, which makes any bios using them that is behind on updates vulnerable. Further, bios updates are still dependent on all the supporting hardware and code to be free of bugs and security holes and for it all to be configured 100% correctly, if the vendor bothers to do it at all, signed code or not.
Spoiler: Fucking Everyone.
Digital signatures are basically worthless now.
I'm just frustrated with the number of signatures that have been forged or stolen in recent years.
Not to say other exploits aren't also in play, but I wouldn't point at EAC being the source. I hate the kernel level stuff too, but the reality is there's no other methods to combat cheaters besides an army of humans reviewing vods who may get it wrong
I mean, we're seeing evidence it really isn't effective at this at all?
all EAC actually does is validate file integrity, if I remember correctly. Valorant is one of the most aggressive and as far as I know doesn't have a serious cheating scene.
I'll install that tonight.
There's a new Thor video that I'm halfway through.
The issue seems to be that there's at least two different exploits being shown.
The first one could very well be that these streamers were fished and compromised individually.
But the same hacker seems to have the ability to do a bunch of server side shit like give everyone free packs (money stuff) and spawn bots in the middle of the match, as well as get into games with said streamers at will (essentially overriding matchmaking.)
And they have been doing this for at least several weeks if not months already.
I can think of at least three different ways this is ABSOLUTELY A HORRIBLE IDEA. But serious... What????
I’m sure saving money by not having to pay for an SMS contract (which not coincidentally makes it harder to find out who’s actually running the show) wasn’t a consideration. Nor was the fact that they would, if they set the mystery threshold correctly, never actually have to pay out their “free premium subscription” offer - the higher the percentage of the user population that signs up to be auth bots the less likely anyone is to meet any threshold.
Plus I’m sure there’s no chance someone could set up a SMS triggered bomb on the service and accidentally implicate some random person from across the continent….
Nintendo Network ID: AzraelRose
DropBox invite link - get 500MB extra free.
Notably, while the NIST have not yet rated this vulnerability, Red Hat rate it a 10.0 on severity.
Hopefully this one was caught before it could make it into the wild. Seems like it may only be in very, very current versions? But regardless I presume this one is going to be on the radar of a huge number of sysadmins.
Notably, this one is hair-raising specifically because it seems that a backdoor was snuck into an otherwise trustworthy repository. I could be wrong, but this looks like a supply-chain attack, and those have the potential to get nasty.
Also, for anyone else interested in more, there's now a reasonable FAQ about the vulnerability that explains it all better than I could.
The latter almost certainly.
Elsewhere people are whipping themselves into a frenzy about it definitely being a nation-state, which mostly tells you those people haven't really thought about it.
Nation-states don't have teams of lone wolf hackers. If you're doing offensive cybersecurity for like, the NSA then you're just another government employee with a mildly interesting to 9-5. You would have reports, managers, taskings and requests and internal funding assignments for different efforts.
Which amongst other things means, given the pretty poor and untested nature of the exploit, that either it's a really poorly run team, or much more likely, wasn't really tested much at all. Because if the NSA is writing an exploit, then they're going to run that out on a server farm and build infrastructure, QA it, the whole lot - just like any other software release process.
Basically this seems like the software equivalent of a mass-shooter.
Dude noticed a 500 ms increase in failed login times in sshd and traced it to back to the liblzma backdoor
This really doesn't help my paranoia, particularly when I notice things taking longer than I'm used to...
Yeah, apparently whoever is behind this had a bunch of sockpuppets they were using to coordinate disinformation.
The biggest narrative they were pushing was that the older versions of libazma were crashing. And thus every distro should be updating to the latest version of liblzma right now.
The more we learn about this, the more it feels like a real bullet dodged.
Really, this should be a giant wake-up call that no one should expect open-source to be a silver bullet. It also points to how ludicrous it is to assume that one or a handful of people should be expected to maintain important libraries for absolutely nothing.
Again: people underestimate what one dedicated crazy person can do.
"Multiple accounts" is a pretty low bar to clear when you have people running literally hundreds of Twitter it's at times.
Like, how much history did these accounts have. How long does it take to fab up a GitHub profile or get an email? Everyone loves talking about this stuff as though any of these things are hard for one guy to do over a couple of months.
Watched a video that tries to explain how the vulnerability works and is wild:
Is basically a binary file sneaked in as a "test case"*, that is buried in a dependency, that rewrites the code during compilation (so none of this is visible on source code at all) and makes it so a call to a particular function calls a different function with the backdoor. And Freund only noticed because the inserted code was hogging a lot of CPU time for apparently no reason.
*Eat shit, developers that said "but is code for testing, it doesn't matter". If it touches production, it absolutely fucking matters.
The Verge article talks about the social engineering aspect of sleazily faking concern to insert their own man into XZ:
But really, the best (only?) place you can really get away with this is a compression library. You need invalid binary files to hide in and few projects have any need for those hanging around. Combine with a completely unreadable build system (configure makefiles) and you can hide pretty well. Without those, you've gotta get way more clever
I'd be very happy if this prompted a movement to burn autotools to the ground though.
hahaha, sucker!
RCE via telemetry, so that's cool
https://labs.watchtowr.com/palo-alto-putting-the-protecc-in-globalprotect-cve-2024-3400/
fucking
lol
Yep this was fun to deal with. Our hosting provider and PA really didn't treat this with the respect it needed and it revealed a lot of weaknesses in how our hosting provider does certain things. Anyway we spend half the day Thursday and literally the entire day yesterday on calls getting this straightened out. And yes, it looks like we were hit, but thankfully they never got around to actually doing anything with the data they got, never logged in and never accessed anything, so we were able to get things changed and and the patch to prevent this applied. Biggest shit show I've been involved in since Log4j
https://medium.com/mitre-engenuity/advanced-cyber-threats-impact-even-the-most-prepared-56444e980dc8
Also GitHub getting in on some anonymous malware hosting