NAS326 how to access to files on disk drive through PC

ak_simoN

My NAS326 was hacked. Some of my files have been encrypted. I disconnected it from the network to save the remaining files before encryption affected the entire disk. When I connect the disk to my PC via USB, I can't access the files. How can I do this through my PC? The system sees the GUID (GPT) partition, but it can't be accessed. How can I resolve this?n hacked and someone encrypt lots of my files. I disconnected

PS. I want to restore my NAS to factory settings. After doing this, if I connect my disks, will I have access to the files or will the NAS force me to format them?

Mijzelf

You'll need a Linux system to read that disk. Any PC booted from a Linux Live USB stick, (like Ubuntu) will do.

Depending on how you arranged the data volume (with or without logical volumes), the disk will be mounted automatically.

I want to restore my NAS to factory settings. After doing this, if I connect my disks, will I have access to the files or will the NAS force me to format them?

A factory reset will only erase the configuration. It doesn't touch the disks, and the disks will be accepted as they are, with the data. You'll only have to re-enable the (custom) shares.

But. If I had to write malware targeting a NAS326, it would survive a factory reset. That's not hard to do, comparing to the difficulty to get access anyway.

ak_simoN

But. If I had to write malware targeting a NAS326, it would survive a factory reset. That's not hard to do, comparing to the difficulty to get access anyway.

So maybe it is better to download firmware from official site and then somehow install it on NAS?

Mijzelf

It won't hurt. But 'factory reset' and 'firmware binaries' are not directly connected. The firmware consists of 2 'blobs': a kernel with included initramfs, which is written to a flash partition, and a file sysdisk.img, stored on a dedictated partition of the disk, which is loopmounted as readonly filesystem.

A factory reset doesn't touch one of these blobs. It just erases a flash partition which is dedicated to store user config, and the directories .media/twonkymedia and .system/guicfg on the data partition.

On the other hand, installing new firmware doesn't touch the user config.

There are several ways to get your own binaries persistent on a ZyXEL NAS:

1. Generate a new kernel, and put the binaries and it's start script in it's initramfs, and flash that.
2. Mount sysdisk.img read-write, and put your binaries in it. Adapt a script here which is called on boot to inject a start command.
3. Put the binaries somewhere on the data partition, and put a script in .system/zy-pkgs/ which starts it, and put that scriptname in the file .system/zy-pkgs/USRPKG_DEPS_START. The firmware will run the script on boot.
4. Create a directory in .PKG/ (the place where packages are installed), and put a script etc/init.d/<directoryname> in it. Get this script started by either adding <directoryname> to .system/zy-pkgs/ZYPKG_DEPS, or by registering the file as package in /etc/zyxel/pkg_conf/status.
5. Inject your startscript in a script from an existing package.

5 has as disadvantage that the script will be deleted when either the package is updated, or deleted. As the malware is supposed to be active at that moment, it could re-inject the startscript in another existing package.

Both ways on 4 has a disadvantage. ZYPKG_DEPS is overwritten each time the firmware downloads a new package database. (Default once a day?) So the malware has to re-inject itself each time that happens. The file /etc/zyxel/pkg_conf/status doesn't survive a factory reset. And packages registered here a visibile on the web interface a installed package.

The problem with 2 is that sysdisk.img is exchanged on a firmware update. That can be prevented, but in that case it's possible that the box won't boot anymore, as the content of sysdisk.img can be incompatible with the scrips in initramfs.

The problem with 1 is that there is very little space. The kernel+initramfs has to fit in 10MB. And it will be overwritten on a firmware update, although you can disable firmware updates completely here.

So I'd choose 3. Enough space, invisible from the webinterface, survives a factory reset, easy.

Fortunately 3 is also easy to remove. If you have mounted the disk on another Linux system, just delete .system/zy-pkgs/USRPKG_DEPS_START. That file is not needed at all for normal firmware action. To be safe I'd delete the complete .system/ directory. My list of possible injections might not be complete.

In case of 4 you only have to look in .PKG/ if there is a directory which doesn't belong to a known package, and delete that. But of course it's better to just delete the whole .PKG directory.

In case of 5 delete the .PKG directory.

In case of 2 you can delete the sysdisk.img file. On next boot the firmware will extract a fresh copy from flash. That could also be infected, so you should upgrade or downgrade the firmware.

In case of 1 you are basically lost. When the kernel/initramfs is compromised, I would have removed the possibility to upgrade the firmware. But the odds that indeed the kernel/initramfs is changed is low. All other methods are the same/compatible for a ZyXEL NAS5xx, but the kernel is NAS326 specific. So the malware writer would have to create at least 2, and maybe more 'blobs', to target all ZyXEL NAS boxes.

So my roadmap to remove the malware:

Mount the disk on another Linux system. Remove .PKG/ and .system/ from the data partition (partition 2) and the files mount.sda1.rw.flag and sysdisk.img from partition 1.

Prepare an upgrade USB stick. Download NAS326.zip, unzip it to a FAT formatted USB stick. Read the readme. You can find firmware here. Put the stick in the NAS, and perform a factory reset. After the reboot the scripts in the initramfs will call the script on the USB stick to upgrade the firmware, overwriting the copy of sysdisk.img in flash, before it can become active.

After that you can put the disk(s) back, and the malware should be inactive. It can still be there, as it can be installed anywhere on the disk, but the startscript is gone.