SSH access to Smile/Stretch (need help)

[Phoenix]

Hi all,

Since we have plain unpacked firmware images (wich we can flash to the device etc.) i don't understand where the SSH password is stored, i did some research and checked these files:

/etc/passwd

Code: Select all

root:x:0:0:root:/root:/bin/ash
ftp:*:55:55:ftp:/home/ftp:/bin/false
network:*:101:101:network:/var:/bin/false
nobody:*:65534:65534:nobody:/var:/bin/false
daemon:*:65534:65534:daemon:/var:/bin/false
stretch:$1$9lXRHfBm$YqKT/lan.UNQmWYRwVhWV1:1000:1000:Stretch User:/home/stretch:/usr/bin/pwstick2clishell
nginx:*:1001:1001:nginx:/dev/null:/bin/false
userp1:$1$Bmzo2ajH$j6QP4AwbNbp2sbMcwYAkh.:1002:1002:p1_user:/dev/null:/bin/ash

/etc/shadow (/etc/shadow- has same contents)

Code: Select all

root:$1$lSwEj9Zc$.d1Eog99MMdeZ2PjPxe7x1:15335:0:99999:7:::
daemon:*:0:0:99999:7:::
ftp:*:0:0:99999:7:::
network:*:0:0:99999:7:::
nobody:*:0:0:99999:7:::

*** No mattter for the Smile or Stretch, the files are all the same! ***

So we have these (salted) UNIX MD5 hashes:
user "root":

Code: Select all

$1$lSwEj9Zc$.d1Eog99MMdeZ2PjPxe7x1

user "stretch":

Code: Select all

$1$9lXRHfBm$YqKT/lan.UNQmWYRwVhWV1

user "userp1":

Code: Select all

$1$Bmzo2ajH$j6QP4AwbNbp2sbMcwYAkh.

Well they aren't that hard , it seems that are the same password as the (user)name:
user: root, password: root
user: stretch, password: stretch
user: userp1, password: userp1

Here is a hashcat screen of the results:

plugwise hashcat results.png (12.11 KiB) Viewed 11493 times

But entering these in a SSH session doesn't work:

plugwise ssh result.png (5.71 KiB) Viewed 11493 times

So why can't we login with these credentials? am i missing something?

[jeroen_]

* Password based authentication might be disabled, thus requiring SSH keys
* The user you are trying might not be in the AllowUsers
* PAM might restrict other things

All kind of reasons thus

Only 'real' way to see what goes wrong is to check the logs on the server side.

You might find some hint in the PuTTY Log, but as you can't change anything on the server side nothing you can really do.

[Phoenix]

* Password based authentication might be disabled, thus requiring SSH keys
* The user you are trying might not be in the AllowUsers
* PAM might restrict other things

All kind of reasons thus

Okey so i'll experiment with this...

Only 'real' way to see what goes wrong is to check the logs on the server side.

Any idea where it could be stored in a linux system)?, maybe i could check NGINX logs...

You might find some hint in the PuTTY Log, but as you can't change anything on the server side nothing you can really do.

We already can get in the system (due to failsave mode and change password) but the trick is to get the 'original' password, withouth flashing or jailbreaking the device...
This should be stored in the firmware somewhere right??, because plugwise can help with problems or settings, or do maintenance from distance??, and thus can access the device?

[jeroen_]

Only 'real' way to see what goes wrong is to check the logs on the server side.

Any idea where it could be stored in a linux system)?, maybe i could check NGINX logs...

nginx has little/nothing to do with sshd. You would have to check the logs on the server side (thus the smile/stretch) and likely those logs are not stored on any saved medium which one can inspect.

Note that the 'shell' in the password file might be restricted too. /etc/shells typically contains a list of 'allowed' shells, hence if /bin/ash is not there then that user effectively cannot log in (at least not without some tricks/settings etc).

You might find some hint in the PuTTY Log, but as you can't change anything on the server side nothing you can really do.

Note that PuTTY is the SSH client you use. Those logs (PuTTY Logs) are thus client side. (click on the program icon in the top left of the PuTTY Window and there is a log there). This will likely show that public-key auth or password auth or rejected or not.

We already can get in the system (due to failsave mode and change password) but the trick is to get the 'original' password, withouth flashing or jailbreaking the device...

Passwords are irrelevant if the system does not use them.

This should be stored in the firmware somewhere right??, because plugwise can help with problems or settings, or do maintenance from distance??, and thus can access the device?

As your host is likely behind a NAT and thus not directly reachable they likely let the plugwise ask their server "do I need to do anything" one in a while in a polling way and then the device executes the command that their server sends back.
The polls for such a thing should be regular, then again every command could have a special command too in the reply.

tcpdumping/wiresharking the device while having them do something is one way to figure this out, if they do not use SSL or you are able to use mitmproxy.

Or you need to go through the firmware identifying any possible REST/API commands and then trying to figure out what they do.


As I noted elsewhere, the closed environment and various other steps that Plugwise have taken have demonstrated that picking that product is not a good idea. Your personal data does not belong in the cloud, it belongs with you, not them.

See also this: http://www.domoticaforum.eu/viewtopic.p ... =15#p63266