4 ms·

If you're just playing with script kiddie stuff and not ridiculous zero days, an up to date virtual machine should be just fine, make sure to keep your VM up to

by arsome 6y ago

If you're just playing with script kiddie stuff and not ridiculous zero days, an up to date virtual machine should be just fine, make sure to keep your VM up to date. VM breaking malware is actually quite rare and usually patched quickly - this is the same stuff that keeps cloud providers safe where anyone can execute arbitrary code in a VM on their systems, if it's good enough for them, it's probably good enough for you, just make sure it has no access to your network. VM detecting malware however is exceedingly common: plan to have to bypass basic VM detection, minimal knowledge of reverse engineering should make that pretty easy. If you want/need to allow it access to the internet for dynamic analysis or botnet monitoring, I'd suggest looking into setting up a separate VM to route all the traffic over Tor or a commercial VPN provider and allowing it access only via that VM. This way if you manage to piss off any script kiddies you won't be the one who gets DDoS'd. Nothing is perfect and if you're serious about this consider separate hardware, but if you're not quite that paranoid this setup is highly workable.

Bnshsysjab 6y ago
If you wanna go a little bit more paranoid, use a dedicated host to virtualise those machines and connect to the host via RDP/whatever, that should create another layer of safety.
- R0b0t1 6y ago
  You may want to connect via a VM, there is a CVE for remote execution in FreeRDP from compromised server. In general anything doing video, image, or audio decompression should be an assumed vector.
  - Bnshsysjab 6y ago
    That’s a fair point.
Bnshsysjab 6y ago
As a side note, and I’ll create a separate thread: say my host is comprised by super sophisticated malware, aside from a reformat what other sanitisation practices can I do? Can I ever trust the hardware again? I don’t think we’re at a point where a firmware compromised graphics card can’t reinfect the processor?
- simlevesque 6y ago
  it always depends on your threat model. If you are against a state actor... I wouldn't trust the hardware.
- krackers 6y ago
  > I don’t think we’re at a point where a firmware compromised graphics card can’t reinfect the processor? We're already at the point where one could theoretically infect the HHD firmware: https://spritesmods.com/?art=hddhack&page=1 https://spritesmods.com/?art=hddhack&page=1
- freakshot 6y ago
  >Can I ever trust the hardware again? I never heard of malware soldering hardware implants onto the device ^^ For firmware you need to dump it and then compare afterwards. >I don’t think we’re at a point where a firmware compromised graphics card can’t reinfect the processor? Nation state based firmware attacks exists since at least a decade. Some professional hacking teams are also already making use of those. You can find POCs, publications, talks, blogposts for probably everything which has flashable firmware. These attacks are very real. Only reasons you don't find that stuff in the wild is because no one is looking for it, your average antivirus won't detect it and it's used mostly for targeted attacks where you need advanced persistence/stealth and early compromise of the OS. Firmware security is a mess. USB, HDD, GPU in particular. Even for all the UEFI verified/secure/whatever boot where at least some more mitigations are in place, holes get found once in a while. Just a while ago had an attacker pwn through a standard qemu/kvm setup trying to flash the BIOS. Wasn't that successful with flashing though ... because muh mitigations. You either need to check or keep the firmware read only.
ChuckMcM 6y ago
That last bit is no joke. I got tired of getting ssh probed so I engineered an ssh server that could kill the client with its response (takes a bit of fuzzing and a lot of requests but they all use the same code so once it works it works well). For about a week it was hilarious to watch what used to be 5 to 15 hits on the server with various account and password combinations turn into exactly one request from an IP and then nothing. What's more, when IPs would come back again and again for another shot, with my ssh client killer that stopped to. I hoped it was because the error was alerting the owner of the machine that something was amiss and they were taking steps to correct it. Needless to say, the script kiddies were not happy. Not happy at all. I think my poor old DSL line was dead for a week, got AT&T to give me a different address block and they said they were black holing "hundreds of gigabites" (which at the time was a lot) of spurious packets. Now I just use fail2ban and ignore them, doesn't help their other victims but it keeps me off their radar. Running the server on AWS hosts might be an interesting alternative.

by arsome 6y ago

Bnshsysjab 6y ago

If you wanna go a little bit more paranoid, use a dedicated host to virtualise those machines and connect to the host via RDP/whatever, that should create another layer of safety.

R0b0t1 6y ago
You may want to connect via a VM, there is a CVE for remote execution in FreeRDP from compromised server. In general anything doing video, image, or audio decompression should be an assumed vector.
- Bnshsysjab 6y ago
  That’s a fair point.

Bnshsysjab 6y ago

As a side note, and I’ll create a separate thread: say my host is comprised by super sophisticated malware, aside from a reformat what other sanitisation practices can I do? Can I ever trust the hardware again? I don’t think we’re at a point where a firmware compromised graphics card can’t reinfect the processor?

simlevesque 6y ago
it always depends on your threat model. If you are against a state actor... I wouldn't trust the hardware.
krackers 6y ago
> I don’t think we’re at a point where a firmware compromised graphics card can’t reinfect the processor? We're already at the point where one could theoretically infect the HHD firmware: https://spritesmods.com/?art=hddhack&page=1 https://spritesmods.com/?art=hddhack&page=1
freakshot 6y ago
>Can I ever trust the hardware again? I never heard of malware soldering hardware implants onto the device ^^ For firmware you need to dump it and then compare afterwards. >I don’t think we’re at a point where a firmware compromised graphics card can’t reinfect the processor? Nation state based firmware attacks exists since at least a decade. Some professional hacking teams are also already making use of those. You can find POCs, publications, talks, blogposts for probably everything which has flashable firmware. These attacks are very real. Only reasons you don't find that stuff in the wild is because no one is looking for it, your average antivirus won't detect it and it's used mostly for targeted attacks where you need advanced persistence/stealth and early compromise of the OS. Firmware security is a mess. USB, HDD, GPU in particular. Even for all the UEFI verified/secure/whatever boot where at least some more mitigations are in place, holes get found once in a while. Just a while ago had an attacker pwn through a standard qemu/kvm setup trying to flash the BIOS. Wasn't that successful with flashing though ... because muh mitigations. You either need to check or keep the firmware read only.

ChuckMcM 6y ago

That last bit is no joke. I got tired of getting ssh probed so I engineered an ssh server that could kill the client with its response (takes a bit of fuzzing and a lot of requests but they all use the same code so once it works it works well). For about a week it was hilarious to watch what used to be 5 to 15 hits on the server with various account and password combinations turn into exactly one request from an IP and then nothing. What's more, when IPs would come back again and again for another shot, with my ssh client killer that stopped to. I hoped it was because the error was alerting the owner of the machine that something was amiss and they were taking steps to correct it. Needless to say, the script kiddies were not happy. Not happy at all. I think my poor old DSL line was dead for a week, got AT&T to give me a different address block and they said they were black holing "hundreds of gigabites" (which at the time was a lot) of spurious packets. Now I just use fail2ban and ignore them, doesn't help their other victims but it keeps me off their radar. Running the server on AWS hosts might be an interesting alternative.