[SOLVED] Trojan horse XPEnology?

[Curiousology]

Hi all,

 

I'd like to point your attention to a posting that appeared recently at Wilders security forums:

 

Well , if anything looks to good to be true...

 

A few weeks ago I surfed past this site -http://www.xpenology.com-. I had an old WHS lying around, and well I like to tweak computers , so I gave it a try.

After some tweaking I found my old WHS was running as a real Synology NAS ...

Nicely done I thought.....

 

Well you guys probably allready know where this is going...

It turned out I installed A gaping backdoor on to my network, and they got in....

 

I have no idea how long they have been looking around or what they did, but it scares me.

 

So what did I do so far:

 

Plugged my router (closed all outgoing ports). Found a furtual netwerk adaptor on one off my computers, wich I removed. Scanned for virus (nod32) and malware (Hitman pro). I use a password manager (Lastpass) with multifactor login. Havn't noticed any misuse there.

 

I formatted all drives in the compromised machine.

 

Still it was stupid, very stupid...

 

What do you guys think, did I do enough damage control?

 

Any additional things I should do?

 

thx for your ( upcomming) advise.

 

Eric

 

Unfortunately "Eric" fails to explain what "gaping backdoor" he thinks he has discovered. What is more, his english skills are not on par with his sense of persecution, giving a hard time to guess what could have gone wrong. But anyway, do you see any evidence for his statement? Are THEY for real? Thanks in advance!

[stanza]

I read that one also, and would like to know others thoughts

 

.

[xrecar]

Installed 4.2 3202. Had port forwarding enabled on my router long story short, massive traffic from China trying to use scripts with alphabetic user/pass attempts. Sometimes for two or more hours.

 

218.108.*.*

124.162.*.*

58.213.*.*

123.163.*.*

 

Just to name a few. Added to blacklist and enabled login attempt blacklist on fail.

 

If it were a backdoor, you think they would have had an easier time. Maybe its just safer not to have port forwarding enabled.

 

Just my experience. Are they just constantly scanning everyone's ports at all times?

 

I wondered as well.

 

Warning Connection 2013/07/02 17:08:21 SYSTEM User [root] from [64.27.26.7] failed to log in via [sSH] due to authorization failure.

Warning Connection 2013/07/02 15:30:54 SYSTEM User [ellen] from [58.213.141.189] failed to log in via [sSH] due to authorization failure.

Warning Connection 2013/07/02 15:30:50 SYSTEM User [ella] from [58.213.141.189] failed to log in via [sSH] due to authorization failure.

Warning Connection 2013/07/02 15:30:46 SYSTEM User [elizabeth] from [58.213.141.189] failed to log in via [sSH] due to authorization failure.

Warning Connection 2013/07/02 15:30:41 SYSTEM User [elisabeth] from [58.213.141.189] failed to log in via [sSH] due to authorization failure.

Warning Connection 2013/07/02 15:30:37 SYSTEM User [elisa] from [58.213.141.189] failed to log in via [sSH] due to authorization failure.

Warning Connection 2013/07/02 15:30:33 SYSTEM User [eliott] from [58.213.141.189] failed to log in via [sSH] due to authorization failure.

 

Etc etc

[rhg84]

Has anybody found any more info on this? My synology log is showing the failed ssh logins from a few different IPs. I'm running the 4.2-3211_x64 build

[Schnapps]

Hi,

I just wanted to clarify some things here:

- The failed ssh logins mean that somebody is trying with a dictionary attack to hack into your device via ssh default port. They usually scan large networks for open ports and then they try to hack in. It can also be in some other application or service like DSM or just FTP. You can protect yourself by changing the default ssh port from 22 to 2222 for example, by deactivating ssh access or just by activating ssh private keys

- If there is or would be a trojan horse in xpenology, it would definitively mean that anytime, from anywhere, somebody can have access on your DSM without you even noticing something strange. Well, actually, it depends on how deep you look.

- personally i didn't saw anything strange but i'm no expert in linux or network security

[quicksilver]

This is a post from the N40L threads (http://www.avforums.com/forums/networking-nas/1786235-xpenology-discussion-2.html#post19299933). I'm just putting here for completeness.

 

From other thread: How does he know it had a backdoor and that was the cause of his problems? Seems a bit odd to me.

 

I agree that it's pretty unlikely but thought that I should investigate/post all the same. I've checked my own firewall monitors for the last week. My two newest SynoloHacs x.x.x.190 and x.x.x.180 are not making may calls to the outside world. I would have expected more traffic if there was a problem but I've not yet tracked down all the places it's tried to reach.

 

x.x.x.180 api.github.com https 443 TCP Default 355.71 KB <1%

x.x.x.180 91-121-40-14.ovh.net http 80 TCP Default 108.19 KB <1%

x.x.x.180 hermes.10trum.de http 80 TCP Default 88.64 KB <1%

x.x.x.180 60-251-87-136.hinet-ip.hinet.net https 443 TCP Default 28.75 KB <1%

x.x.x.180 vserver49.axc.nl http 80 TCP Default 15.63 KB <1%

x.x.x.180 lvps5-35-244-237.dedicated.hosteurope.de http 80 TCP Default 13.27 KB <1%

x.x.x.180 wa3.rzone.de http 80 TCP Default 12.34 KB <1%

x.x.x.180 546bcd0c.cm-12-4d.dynamic.ziggo.nl http 80 TCP Default 9.88 KB <1%

x.x.x.180 192.30.252.137 https 443 TCP Default 9.45 KB <1%

x.x.x.180 imu307.infomaniak.ch http 80 TCP Default 8.48 KB <1%

x.x.x.180 ns395541.ovh.net http 80 TCP Default 1.47 KB <1%

 

github seems ok... prob an update check

91-121-40-14.ovh.net... synocommunity

hermes.10trum.de... ?

60-251-87-136.hinet-ip.hinet.net.. ?

vserver49.axc.nl.. ?

lvps5-35-244-237.dedicated.hosteurope.de.. Pantofflhelden?

wa3.rzone.de..?

546bcd0c.cm-12-4d.dynamic.ziggo.nl.. ?

https://192.30.252.137/..?

imu307.infomaniak.ch..?

ns395541.ovh.net... Wombles NZB index

 

the other box (190)

 

x.x.x.190 31-6-72-106.the.ccsleeds.co.uk https 443 TCP Default 1.57 MB <1%

x.x.x.190 91-121-40-14.ovh.net http 80 TCP Default 476.93 KB <1%

x.x.x.190 api.github.com https 443 TCP Default 226.82 KB <1%

x.x.x.190 hermes.10trum.de http 80 TCP Default 94.03 KB <1%

x.x.x.190 60-251-87-136.hinet-ip.hinet.net https 443 TCP Default 29.44 KB <1%

x.x.x.190 52493be6.cm-4-2a.dynamic.ziggo.nl http 80 TCP Default 8.19 KB <1%

x.x.x.190 192.30.252.139 https 443 TCP Default 8.17 KB <1%

x.x.x.190 ns395541.ovh.net http 80 TCP Default 4.31 KB <1%

x.x.x.190 199.27.76.133 http 80 TCP Default 2.49 KB <1%

x.x.x.190 103.245.223.196 http 80 TCP Default 2.39 KB <1%

 

31-6-72-106.the.ccsleeds.co.uk... Synology cloud service

91-121-40-14.ovh.net.. Syno Community

api.github.com... git

hermes.10trum.de... ?

60-251-87-136.hinet-ip.hinet.net..?

52493be6.cm-4-2a.dynamic.ziggo.nl..?

192.30.252.13.. ?

ns395541.ovh.net... Wombles NZB index

199.27.76.133.. github

103.245.223.196.. github

 

As mentioned above... Failed SSH logins are NOT evidence that DSM has been hacked. any/all ssh servers attached to the internet get probed regularly. Personally I think that it's crazy not to use cert based authentication on ssh and a more obscure port than 22 on a machine that's accessible publicly but that's a discussion for a different thread.

 

I continue to monitor but so far no indications other than the sites reported above, some of which still need to be checked out.

 

My gut feel is that we're OK but I'm still nervous and would love to hear from whomever compiled the release that we're using and at some point would like to compile myself.

Edited July 17, 2013 by Guest

[XPEH]

As mentioned above... Failed SSH logins are evidence that DSM has been hacked. any/all ssh servers attached to the internet get probed regularly.

.....

My gut feel is that we're OK but I'm still nervous and would love to hear from whomever compiled the release that we're using and at some point would like to compile myself.

 

Failed SSH logins are NOT evidence that DSM has been hacked. Successful logins are.

[wenlez]

failed SSH attempt doesn't mean your server is hacked. If you ever own a cloud server, you will also notice there are hundreds of these attempts from the internet.

 

What you failed to do here is to use the firewall. For those of you that see these messages from the log, you will need to disable your DMZ, and assign the trusted IP to use port 22. that's it.

 

Regard of a backdoor..... well, if a person has a backdoor login, then it would not show a failed login attempt. Guessing a login is not a backdoor.

[Schnapps]

Thread marked as solved. Hope you don't have any complains with this action

[quicksilver]

Failed SSH logins are NOT evidence that DSM has been hacked. Successful logins are.

 

Absolutely right. XPEH, thanks for the correction. Not sure why I missed the word NOT. "as mentioned above" was referring to the comment that they were not evidence of being hacked. Must be getting old or just not being careful enough when typing.

[andyl9063]

yeah just want to mention i got this error too. Failed ssh connection. After I block the connection from my firewall, no more issues.

[fonix232]

I get no SSH connections at all (though the port is forwarded), but what I get is daily 5-10 failed login. I use a free dynamic DNS solution (might be the cause), plus most of the ports are forwarded (too lazy to set up a proper VPN, plus current internet is SLOOOOOOW).

 

Apart from this, no irregular behavior, nothing extra. Though ONCE I got hacked, when accidentally reset the admin password to admin (for about two days). All that happened was that some chinese downloaded soap operas and stuff like that, of course in chinese. Removed them, changed the password, no problem since.