Shuttle omninas kd20 a.k.a oxnas820

[wicked]

Tun.ko was built on the shuttle box with chrooted debian from nsa310 - maybe this is the issue. I'll try to experiment with clean ffp when I will make it fully work on nas.

In the mean time if someone needs the sshd on Omninas KD20 the method is described in details here http://asham.ca/hardware/2013/12/gettin ... inas-kd20/

This method is available up to firmware revision 2.35. It's a nasty bug that allows everyone to change the root password and even more so while using nas with this firmware put it locally without any access from the internet.
If someone finds an sshd hack in safer firmwares (2.38) please post it here.

[Mijzelf]

Looking at the rootfs as provided in 'OMNINAS Firmware update via USB' KD20.zip (2.37.20140527), it seems there is a page /admin/ssh.php in which you can start an ssh daemon.
BTW, *don't use this file* I think it will brick your box.

[wicked]

Looking at the rootfs as provided in 'OMNINAS Firmware update via USB' KD20.zip (2.37.20140527), it seems there is a page /admin/ssh.php in which you can start an ssh daemon.

It is password protected (unlike /IO/ssh.php)

and yes, it will brick the box

[Mijzelf]

The script does:

Code: Select all

<?
//check password{{
if(!$_COOKIE['aton_nas_ssh']){
        if (!isset($_SERVER['PHP_AUTH_USER'])) {
    // if is null, send header to show dialog box 
    header('WWW-Authenticate: Basic realm="Administrator"');
    header('http/1.0 401 Unauthorized');
    echo 'Please enter user and password';
    exit;
        } else {
                
                $pwd = $_SERVER['PHP_AUTH_PW'];
                //$realpwd = "SqwfJ0XVOC/ZE";
                $realpwd = "ASI/prMp4QNHc";
                
        if (($_SERVER['PHP_AUTH_USER'] == "atonnas") && (crypt($pwd, $realpwd)==$realpwd)) {
        //if (($_SERVER['PHP_AUTH_USER'] == "atonnas") ) {
                $cartoon_time = time() + (10*60);    // set cookie for 10 minutes
                setcookie ('aton_nas_memocom','memocom_admin', $cartoon_time);           
        } else {
                echo "Invalid user name or password <br/>";
                echo "Please reopen browser, and try it again";
                exit;
        }
        } 
}       
//check password}}      
?>

So you have 2 'real passwords' to check, user 'atonnas', and if that fails, it might be enough to set a cookie 'aton_nas_ssh'

[Mijzelf]

The script does:

Code: Select all

<?
//check password{{
if(!$_COOKIE['aton_nas_ssh']){
        if (!isset($_SERVER['PHP_AUTH_USER'])) {
    // if is null, send header to show dialog box 
    header('WWW-Authenticate: Basic realm="Administrator"');
    header('http/1.0 401 Unauthorized');
    echo 'Please enter user and password';
    exit;
        } else {
                
                $pwd = $_SERVER['PHP_AUTH_PW'];
                //$realpwd = "SqwfJ0XVOC/ZE";
                $realpwd = "ASI/prMp4QNHc";
                
        if (($_SERVER['PHP_AUTH_USER'] == "atonnas") && (crypt($pwd, $realpwd)==$realpwd)) {
        //if (($_SERVER['PHP_AUTH_USER'] == "atonnas") ) {
                $cartoon_time = time() + (10*60);    // set cookie for 10 minutes
                setcookie ('aton_nas_memocom','memocom_admin', $cartoon_time);           
        } else {
                echo "Invalid user name or password <br/>";
                echo "Please reopen browser, and try it again";
                exit;
        }
        } 
}       
//check password}}      
?>

So you have 2 'real passwords' to check, user 'atonnas', and if that fails, it might be enough to set a cookie 'aton_nas_ssh'

and yes, it will brick the box

Experience?

[wicked]

and yes, it will brick the box

Experience?

to be continued in another thread

[christiaan]

I've been succesfull in decrypting (and encrypting) the firmware using the following commands.

To Decrypt

Code: Select all

openssl enc -des3 -d -a -k sohmuntitnlaes -in OMNINAS-7821_2.38.20140728.TAR.GZ -out firmware_decrypted.TAR.GZ

To Encrypt

Code: Select all

openssl enc -des3 -e -a -k sohmuntitnlaes -in firmware_decrypted.tar.gz -out firmware_encrypted.TAR.GZ

However it contains a ubi file which I have difficulties mounting.

Maybe someone with more experience than me can do something with this info

[Peacemaker]

Hey,
Thanks for this Information.

I've rigth now runnig Debian Wheezy with a patched 2.6.31 Kernel running on the KD20. But right now I is not fully running and with a few bugs.
If I worked out a few thinks more I'll provide a "beta" package.

[christiaan]

Hey,
Thanks for this Information.

I've rigth now runnig Debian Wheezy with a patched 2.6.31 Kernel running on the KD20. But right now I is not fully running and with a few bugs.
If I worked out a few thinks more I'll provide a "beta" package.

You got that running without altering the nand flash? Then I'll be the first to try!

[Peacemaker]

NO, I flashed the Kernel and the Initrd to the nand, and modified the env to load the rootfs from a USB-stick.


But I think there might be a way, to don't touch the nand:

The Soc can load stage1 and Uboot from sata and then you can load a everything you want from there.
I used this way to unbrick my KD20. The problem there is U-boot 1.1.4 and 3.1X Kernel form kefs is not working propably

Uboot: usb load and ethernet not working
Kernel: Sata not working

p.s.: What is the problem with alternating the nand, if you have a backup?

[christiaan]

But I think there might be a way, to don't touch the nand:

Yes we've been exploring that possibility here. Might contain some useful hints.

I take it you've used a serial cable? If so, would you mind sharing how you opened the case?

p.s.: What is the problem with alternating the nand, if you have a backup?

Nothing I guess if you have a serial cable or other means to restore a nand backup.

[Peacemaker]

Yes, I uesd the UART.

And I see no way to get around uart at this state.

Here you see everything disassembled:
https://plus.google.com/photos/+EugeneC ... 3634658177

https://gitorious.org/openwrt-oxnas/pages/omninas-kd20

thx to crosser for that, and he provided me with the 2.6.31.14_7821.diff

for getting root access my on the vendors firmware:
just write your own passwd in the /etc/passwd of the vendors ubi_rootfs, and flash it via usb.
but I did not drive this to an end.

[Peacemaker]

So, it is looking quite good, that I'll be able to make an Image to boot debian fully from SATA without touching anything on this device.

[christiaan]

So, it is looking quite good, that I'll be able to make an Image to boot debian fully from SATA without touching anything on this device.

Nice, do you got SATA working with that kernel? If not did you already ask Shuttle support for the sources? Looking at the other topic about the KD21 they seem to be willing to share.

When you have a image ready I have the stuff ready on my desk already to try it out

[Peacemaker]

I got the sources form shuttle,
I just ues a patched stage1 to 850mhz( or less) recompiled u-boot and patched 2.6.31 Kernel.

What is left to do so far is changing the env, that you do not need a Serial to set the right boot image & fix the led.