Can the peppermint bootable usb drive be permanently infected if malware gets root access?

linux4evr5581 · 04-19-2017, 01:54 PM

Quote:

Originally Posted by 273

Surely if the malware runs on the "live" OS then it will have the same access as that OS to any storage?
Perhaps another good reason not to run as root even on "non-persistent" installs?

I'm pretty sure that would likely be the case depending on the type of malware and it's intended function. So yeah that would be another good reason not to use root.

PCNetSpec · 04-19-2017, 08:47 PM

Permanently - (on a non-persistent LiveUSB) Only if the malware were somehow able to unpack the squashfs (or initramfs), edit it, and repack it. I'm unaware of anything that currently does that, and if/when it can no distro on a USB stick will be proof against it.

The only other method I can think of would be some kind of SYSLINUX bootloader virus, again no distro is proof against that in Legacy BIOS mode, but UEFI with Secureboot should (theoretically) mitigate against this.

If you're asking if a Live session can temporarily pick up malware (and load it into RAM) whilst being run, that then goes on to "infect" the contents of the HDD permanently .. sure it can, doesn't matter if it's LiveUSB or LiveDVD, but Peppermint (version 6 and 7) does NOT automatically mount HDD partitions in a Live session (this is NOT the same as saying they cannot be mounted, just that they are not by default).

So the only correct answer would be YES it's "theoretically" possible, but HIGHLY unlikely.

Ulysses_ · 04-20-2017, 02:33 AM

Thanks. Another issue raised is what do we do with the internal HDD, if not physically take it out?

linux4evr5581 · 04-20-2017, 09:47 AM

Quote:

Originally Posted by Ulysses_

Thanks. Another issue raised is what do we do with the internal HDD, if not physically take it out?

For live sessions keep disks unmounted and encrypt them.. For installed OSes set your partition options in /etc/fstab to noexec so nothing can execute, and use a MAC like AppArmor.. Usually malware that resides in RAM cant survive unless someone has rewritten the BIOS.

sundialsvcs · 04-20-2017, 11:27 AM

Malware isn't biological, and it isn't all-powerful. It runs as "you." Therefore, if you carelessly allow yourself "the run of the machine," the malware can do the same.

This is why you should create a non-privileged account for these purposes, and always use it. You can go one step farther and use containers. Never respond to any prompt that asks for a powerful password – or, any password at all. This powerless user can only affect files in its own /home.

Likewise, the account that you use for daily affairs should be non-privileged. Only one user should have the power to sudo su and thereby become root. Get used to it.

Also, consider using a designated but non-privileged account to maintain software and other shared resources. Only this user would have read/write access to them.

Most crimes are simply crimes of opportunity. So, don't create opportunity! The pizza-delivery cat burglar comes to your front door and finds that it and the nearby windows are locked. He moves on – there's another house next door and next door to that, so why bother with yours? Malware has no particular interest in "you."

Ulysses_ · 04-20-2017, 11:45 AM

We're not talking about virus-like automatic malware, we're talking about humans, trying to remote control what they can without your permission when you knowingly mix with potentially dangerous people in search of underground knowledge on security. I'd need to try some of their recommended software too, which may need root access. It is ok if the computer "gets owned" as they say in hacker jargon, as long as this is non persistent.

sundialsvcs · 04-20-2017, 12:41 PM

A startling number of machines out there in coffee shops are susceptible to remote control, for the convenience of system administrators at their place of business. But, this remains active when the computers are not attached to the corporate network!

Many "road warrior" machines, when attached to "a network," trust(!) that network, as though it were the network in the office. Furthermore, they connect wirelessly. There's a very well known case of an industrial spy who simply rented office-space on the floor above his target. The wireless network being used downstairs was his for the taking.

linux4evr5581 · 04-20-2017, 01:01 PM

That's why you setup "zero trust" network that uses 802.1x, and put all insecure devices in a guest network (a feature some routers have) that's in a VLAN ( a feature some switches have)..

Ulysses_ · 04-20-2017, 03:46 PM

Just tried to dismount the usb flash drive and I am not allowed to, despite root access:

sudo umount /dev/sdb1
umount: target is busy

Can this be of use? Maybe by booting off a squashfs file residing in the internal HDD and occupying the entire drive so no one, even root, can change anything on the internal drive?

Ulysses_ · 04-20-2017, 03:57 PM

Here's the complete list of mounts:

Code:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=1942288k,nr_inodes=485572,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=393012k,mode=755)
/dev/sdb1 on /cdrom type vfat (ro,noatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/loop0 on /rofs type squashfs (ro,noatime)
/cow on / type overlay (rw,relatime,lowerdir=//filesystem.squashfs,upperdir=/cow/upper,workdir=/cow/work)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/hugetlb type cgroup (rw,nosuid,nodev,noexec,relatime,hugetlb)
cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=25,pgrp=1,timeout=0,minproto=5,maxproto=5,direct)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
fusectl on /sys/fs/fuse/connections type fusectl (rw,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /run/user/999 type tmpfs (rw,nosuid,nodev,relatime,size=393012k,mode=700,uid=999,gid=999)
gvfsd-fuse on /run/user/999/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,relatime,user_id=999,group_id=999)
/dev/sda1 on /home/peppermint/temp type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

michaelk · 04-20-2017, 04:02 PM

squashfs is used with a unionfs so that the flash drive and RAM appear as one filesystem. This is why you can not unmount the drive. If you want to remove the flash drive then the OS needs to run entirely from RAM.

There are several but as already suggest tails is perfect for your intended purpose. You can not mount an internal drive any any persistent storage is written to a second drive not the primary so it can not be hacked. Since your using a tor network it will take a bit of work for your "new friends" to find you.

https://en.wikipedia.org/wiki/List_o...t_run_from_RAM

Ulysses_ · 04-20-2017, 04:35 PM

Unfortunately TOR does not support the Secure Boot option of UEFI and my computer is stuck with Secure boot, it does not have an option to disable it, aka legacy mode.

Ulysses_ · 04-20-2017, 04:41 PM

I do not want to remove the flash drive, I want to find out whether root can dismount it and remount it as read-write and if not, mimic usb boot on the internal HDD so it cannot be harmed either.

PCNetSpec · 04-21-2017, 07:05 AM

You might want to take a look at this:
https://www.logicsupply.com/explore/...-linux-system/
which effectively makes an installed Linux system read-only .. layering changes to a temporary filesystem that will be lost on reboot (tested on Peppermint 7 in Legacy BIOS, but I can see no reason it wouldn't work in UEFI/Secureboot)

Still gives you the option to boot an earlier kernel in read/write mode, but for that you'd need local access.

Hint - It'd be a very good idea to create a backup copy of the current initrd.img (as suggested in one of the comments on that page) before trying this .. so it can more easily be undone.

PCNetSpec · 04-21-2017, 01:26 PM

Quote:

Originally Posted by Ulysses_

I do not want to remove the flash drive, I want to find out whether root can dismount it and remount it as read-write and if not, mimic usb boot on the internal HDD so it cannot be harmed either.

If I'm understanding this question correctly, you're asking if you can remount the root of the LiveUSB stick whilst booted to it ?

YES:

Code:

sudo mount -o remount,rw /cdrom

But this won't help you edit the squashfs which is a loop mounted block device .. even:

Code:

sudo blockdev --setrw

doesn't seem to help there.

For malware to edit the squashfs permanently it'd somehow have to unpack the squash, edit, then write it back to the USB stick whilst actually booted to it .. I hesitate to say that's impossible, in fact thinking about it it probably could be done, but I'm not aware of any malware that currently does this.

At best all you can do is make things as difficult as possible, by limiting privileges, being cautious, and presenting the smallest attack surface as possible.

The only way I can think of where you're intentionally going to let "nasties" in, and want to be 100% sure they don't persist is to use a non writeable medium such as DVD-R, or a write protectable medium such as SDcard or a USB stick with write-protection .. or to recreate the LiveUSB each boot.
(and even then there are "possible" persistence vectors such as BIOS and firmware hacks .. though Secureboot may mitigate this to an extent)

In the end I guess how far your willing to go with protection all boils down to your paranoia levels...

There's only one way to have a 100% secure system .. and that's to never turn it on .. in the real world it's all about degree