4 ms·

This machine is 100% still compromised... You have an actor who has system level permissions that allowed creating and registering launchd scripts. A browser

This machine is 100% still compromised... You have an actor who has system level permissions that allowed creating and registering launchd scripts. A browser extension cannot do that by itself. You've stopped the obvious parts of this malware, and that's absolutely all. This machine needs to be wiped. If you don't have backups - move critical files and media to a new machine, ideally running a different OS, or to a cloud service. Then do a completely fresh install of the OS.

bobbiechen 5y ago
Thanks for putting it so clearly, that makes sense. We'll do this soon.
- unnouinceput 5y ago
  And change your internal network passwords as well after you do the fresh install. The old ones are probably already in the hands of that malware author(s)
nqzero 5y ago
certainly if the user executes or opens them (eg for a .doc) they're powned. but automated systems can also have exploits. i'm trying to make a list of these services (and maybe disable them) to minimize my footprint (often testing out untrusted code from github etc in a small secretive community, ie easy to target) for ubuntu 21.04+, i'm aware of: - gnome-tracker-miner - gnome-thumbnailer (may require browsing in nautilus) - mlocate at least the first two appear to be sandboxed, though unclear of the efficacy. any other services that you're aware of that would be automated vectors ?
- TheDong 5y ago
  > i'm trying to make a list of these services (and maybe disable them) to minimize my footprint (often testing out untrusted code from github etc in a small secretive community, ie easy to target) If you're running a lot of "untrusted code from github", then the list of services you have enabled or disabled on your system isn't going to make a difference. For someone who frequently runs untrusted code, I'd recommend learning any of: 1. qemu / virsh / how to quickly and efficiently spin up isolated VMs 2. ec2/GCP/digital ocean/any similar VPS provider 3. QubesOS https://www.qubes-os.org/ https://www.qubes-os.org/ The first two options will be a more secure way to run untrusted code and provide actual protection. The 3rd has better usability, though isn't as secure. Disabling local thumbnailing services... yeah, sure, do that, but don't expect it to really do much against "testing out untrusted code".
  - nqzero 5y ago
    i explicitly said "if the user executes ... they're powned" and never said anything about "running". you're implying i'm taking far more risk than i am i'm trying to understand (and minimize, if needed) the automated risks of having untrusted files *stored* locally, which would give me time to read them and develop a level of trust fwiw, if i need to run something untrusted, i'm using #2 some, but mostly: 4. a 2nd (untrusted) machine running locally, which is beefier than my laptop and also used for benchmarking. i've never seen any unusual behavior from it, but treat it as though it's compromised
  - axytol 5y ago
    Some good tips on running untrusted code in VMs. If possible I'm interested to learn why you consider qemu based VMs as more secure than QubesOS? If I get it right QubesOS is Xen based so is it about the hypervisor or something else that favours qemu in your opinion?
    - TheDong 5y ago
      QubesOS inherently has a higher attack surface due to the features it's added to be more usable. An AWS VM in the cloud I ssh into can't possibly snoop on another window I have open. QubesOS on the other hand includes usability features like displaying graphical interfaces from VMs, clipboard sharing features, etc etc https://www.qubes-os.org/doc/gui/ https://www.qubes-os.org/doc/gui/ These usability features increase attack surface, whether they're implemented on top of a Xen or KVM hypervisor. My assumption for a local qemu setup is that the user wouldn't use things like 9p or display sharing, which I think means a smaller enough attack surface to make a difference.
jokoon 5y ago
Might not be enough, since some viruses are using firmwares and other things to be made more difficult or impossible to remove properly, if you can remember the story about HDD firmware being infected. Rootkit have been existing for a long time now. Not to mention the intel management engine thing, wifi firmwares, etc. I believe in the conspiracy theory that computers are now built with low security in mind, to make it easier to compromise by 3 letter agencies, as long as those 3 letters agencies are holding supremacy in the cyber weapon warfare. This still enables a few rogue black hats to lockpick those vulnerabilities every once and then, until most of them are caught and neutralized (either sent to prison or forced to work for those agencies).
- mistrial9 5y ago
  > Might not be enough, since some viruses are using firmwares and other things to be made more difficult or impossible to remove properly I object to this vague and incurable diagnosis as an everyday response. I don't enjoy this topic but I practice good hygeine, habits and backups.. keep the possibility in mind? sure, lets not be naive. Every time, destroy the hardware? no, just no

bobbiechen 5y ago

Thanks for putting it so clearly, that makes sense. We'll do this soon.

unnouinceput 5y ago
And change your internal network passwords as well after you do the fresh install. The old ones are probably already in the hands of that malware author(s)

nqzero 5y ago

certainly if the user executes or opens them (eg for a .doc) they're powned. but automated systems can also have exploits. i'm trying to make a list of these services (and maybe disable them) to minimize my footprint (often testing out untrusted code from github etc in a small secretive community, ie easy to target) for ubuntu 21.04+, i'm aware of: - gnome-tracker-miner - gnome-thumbnailer (may require browsing in nautilus) - mlocate at least the first two appear to be sandboxed, though unclear of the efficacy. any other services that you're aware of that would be automated vectors ?

TheDong 5y ago
> i'm trying to make a list of these services (and maybe disable them) to minimize my footprint (often testing out untrusted code from github etc in a small secretive community, ie easy to target) If you're running a lot of "untrusted code from github", then the list of services you have enabled or disabled on your system isn't going to make a difference. For someone who frequently runs untrusted code, I'd recommend learning any of: 1. qemu / virsh / how to quickly and efficiently spin up isolated VMs 2. ec2/GCP/digital ocean/any similar VPS provider 3. QubesOS https://www.qubes-os.org/ https://www.qubes-os.org/ The first two options will be a more secure way to run untrusted code and provide actual protection. The 3rd has better usability, though isn't as secure. Disabling local thumbnailing services... yeah, sure, do that, but don't expect it to really do much against "testing out untrusted code".
- nqzero 5y ago
  i explicitly said "if the user executes ... they're powned" and never said anything about "running". you're implying i'm taking far more risk than i am i'm trying to understand (and minimize, if needed) the automated risks of having untrusted files *stored* locally, which would give me time to read them and develop a level of trust fwiw, if i need to run something untrusted, i'm using #2 some, but mostly: 4. a 2nd (untrusted) machine running locally, which is beefier than my laptop and also used for benchmarking. i've never seen any unusual behavior from it, but treat it as though it's compromised
- axytol 5y ago
  Some good tips on running untrusted code in VMs. If possible I'm interested to learn why you consider qemu based VMs as more secure than QubesOS? If I get it right QubesOS is Xen based so is it about the hypervisor or something else that favours qemu in your opinion?
  - TheDong 5y ago
    QubesOS inherently has a higher attack surface due to the features it's added to be more usable. An AWS VM in the cloud I ssh into can't possibly snoop on another window I have open. QubesOS on the other hand includes usability features like displaying graphical interfaces from VMs, clipboard sharing features, etc etc https://www.qubes-os.org/doc/gui/ https://www.qubes-os.org/doc/gui/ These usability features increase attack surface, whether they're implemented on top of a Xen or KVM hypervisor. My assumption for a local qemu setup is that the user wouldn't use things like 9p or display sharing, which I think means a smaller enough attack surface to make a difference.

jokoon 5y ago

Might not be enough, since some viruses are using firmwares and other things to be made more difficult or impossible to remove properly, if you can remember the story about HDD firmware being infected. Rootkit have been existing for a long time now. Not to mention the intel management engine thing, wifi firmwares, etc. I believe in the conspiracy theory that computers are now built with low security in mind, to make it easier to compromise by 3 letter agencies, as long as those 3 letters agencies are holding supremacy in the cyber weapon warfare. This still enables a few rogue black hats to lockpick those vulnerabilities every once and then, until most of them are caught and neutralized (either sent to prison or forced to work for those agencies).

mistrial9 5y ago
> Might not be enough, since some viruses are using firmwares and other things to be made more difficult or impossible to remove properly I object to this vague and incurable diagnosis as an everyday response. I don't enjoy this topic but I practice good hygeine, habits and backups.. keep the possibility in mind? sure, lets not be naive. Every time, destroy the hardware? no, just no