471–480 of 500 posts
Has anyone tried the PoC against one of the anomalous process behavior tools? (Carbon Black, AWS GuardDuty, SysDig, etc.) I’m curious how likely it is that someone would have noticed relatively quickly had this rolled forward and this seems like a perfect test case for that product category.
Earlier quoted context omitted.
Depends how closely the exploit mirrors and/or masks itself within normal compression behavior imo. I don’t think GuardDuty would catch it as it doesn’t look at processes like an EDR does (CrowdStrike, Carbon black), I don’t think sysdig would catch it as looks at containers and cloud infra. Handwaving some complexity here, as GD and sysdig could prob catch something odd via privileges gained and follow-on efforts by…
Guard Duty does have some ptocees level monitoring with some recent additions: https://aws.amazon.com/blogs/aws/amazon-guardduty-ec2-runtim... The main thing I was thinking is that the audit hooking and especially runtime patching across modules (liblzma5 patching functions in the main sshd code block) seems like the kind of thing a generic behavioral profile could get but especially one driven by the fact that sshd…
Earlier quoted context omitted.
When loading liblzma, it patches the ELF GOT (global offset table) with the address of the malicious code. In case it's loaded before libcrypto, it registers a symbol audit handler (a glibc-specific feature, IIUC) to get notified when libcrypto's symbols are resolved so it can defer patching the GOT.
> When loading liblzma, it patches the ELF GOT (global offset table) with the address of the malicious code. How was this part obfuscated/undetected?
Earlier quoted context omitted.
Yes.. The RCE happens at the connection stage before anything is logged.
That's insane. How exactly does this happen? Are there no EDR/IDS who can detect an RCE at the connection stage?
Earlier quoted context omitted.
That would look the same as a random failed ssh login, which happens all the time. The connection isn't maintained past that point (unless the payload chooses to do so).
It would be similar but the payload is going to be abnormally large compared to other failed login attempts.
Earlier quoted context omitted.
That is not how disclaimers work. You cannot disclaim liability for intentionally harming someone. You also cannot avoid criminal charges for a crime simply by shouting "don't blame me"
I did setup the question in a way that the developer doesn’t harm someone themselves but sells it to a state actor. I.e extremely similar outcome to finding a zero day and selling it to a state actor except it is “more” secure - need private key. The point about MIT is that they are saying to the world when publishing “as is” folks. Not claiming I haven’t backdoored it for Uncle Sam.in fact I’m not claiming anything,…
Is there anything actually illegal here? Like is it a plausible “business” model for talented and morally compromised developers to do this and then sell the private key to state actors without actually breaking in themselves or allowing anyone else to break in. Edit: MIT license provides a pretty broad disclaimer to say it isn’t fit for any purpose implied or otherwise.
I brought this up in an earlier thread and got heavily downvoted. https://news.ycombinator.com/item?id=39878227
Earlier quoted context omitted.
one question I still have is what exactly the performance issue was? I heard it might be related to enumeration of shared libraries, decoding of the scrambled strings[1], etc. anyone know for sure yet? one other point for investigation is if the code is similar to any other known implants? like the way it obfuscates strings, the way it detects debuggers, the way its setting up a vtable, there might be code fragments…
It's the symbol lookup that's slow.
Earlier quoted context omitted.
That is not how disclaimers work. You cannot disclaim liability for intentionally harming someone. You also cannot avoid criminal charges for a crime simply by shouting "don't blame me"
I did setup the question in a way that the developer doesn’t harm someone themselves but sells it to a state actor. I.e extremely similar outcome to finding a zero day and selling it to a state actor except it is “more” secure - need private key. The point about MIT is that they are saying to the world when publishing “as is” folks. Not claiming I haven’t backdoored it for Uncle Sam.in fact I’m not claiming anything,…
The harm in question is causing the backdoor to be inserted in the first place. Its irrelavent what else you do, like selling it, although that could be a separate crime.
> The point about MIT is that they are saying to the world when publishing “as is” folks. Not claiming I haven’t backdoored it for Uncle Sam.in fact I’m not claiming anything, use at your own risk.
Just because you think that is what those words mean, doesn't mean that is what those words actually mean.
> It used to be the law to implicitly do this by weak encryption for exports.
Not comparable. Even now, the MIT license would probably protect you from any consequenes of using super weak encryption. It would not protect you from the hypothetical you setup. They are very different sutuations.