NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
ReadyNAS Pro Business Hacked/Compromised
I have a real problem. About a month ago, my ISP (Time Warner) quarantined my public IP. When I called them, I was told that there was a complaint from Europe that my public IP was trying to brute force the root password on one of their servers. Time Warner re-enabled my Internet access and told me to scan all of my computers for viruses and trojans. I have mostly Macs at home, but I do have one Windows VM. I ran multiple anti-virus programs and scanners and found nothing. So, I hoped the problem would go away by itself.
Today my public IP was quarantined again by Time Warner. When I called them, they told me that another sysadmin complained about my public IP trying to brute force the root password on their server. This time it got my attention (partly because I work from home and I need Internet, so I can’t have this happening again). Additionally, this time Time Warner threatened to disconnect my account to “protect themselves” from the liability.
So, I decided to change my router’s public IP address, thinking that someone may be spoofing my IP, and the attack really does not come from within my network. As soon as I changed the MAC address on the router’s WAN interface and acquired a new IP, I decided to clear the NAT table to get rid of the connections that could be hung due to my public IP having just changed. Once I cleared the NAT table, I issued the “show ip nat translations” command in the Cisco router and saw this:
This is just a small excerpt. There were literally hundreds of fresh NAT rules with random public IP addresses and destination port 22 (which is SSH). The reason I’m posting this here is because the inside source IP (192.168.200.30) is my ReadyNAS Pro Business.
So, it appears that the ReadyNAS is scanning hundreds (and probably thousands) of IPs on the Internet trying to establish a connection on port 22 (SSH).
The following output is from the log of the server belonging to the guy who complained to Time Warner about my public IP attacking his server on December 2, 2012. This log was emailed to me by Time Warner today.
The 174.98.137.x IP address is the public IP that my Cisco router had before me getting a new IP (174.98.157.x) today.
Finally, below is an excerpt from the log that was emailed to me by the person who complained about my IP trying to brute force the user login into one of his servers back in early November, 2012:
This attack lasted for over 40 minutes with hundreds of user names tried.
Back in June of 2012, my ReadyNAS started misbehaving. It would become unresponsive once every two to three weeks, and I had to power cycle it with the power button in order to bring it back online. I contacted Netgear support and they worked with me for several months to determine what the problem was. The case # is 19196769. Netgear asked me to provide SSH access to the ReadyNAS for them and even asked me to give them the root password, which I pasted in the ticket notes. Later, it appeared that the root password was not required for them to have access to the RadyNAS, but they had asked for it, and I gave it to them. Additionally, I kept the SSH access open for them for several months. My suspicion is that my ReadyNAS was somehow compromised because of this SSH access being open for several months. I killed it in November after I had the first incident with Time Warner quarantining my IP and when I saw the log with my IP trying to SSH to a server in Europe with various user names. Back then I suspected this brute-force attack was launched from my ReadyNAS because I saw that there was a login registered from a Netgear IP around the time when the attack was reported. There was no reason for Netgear to log in to my ReadyNAS on November 12 (because all the troubleshooting of my original problem had been finished), so I suspected that it was their automated login server that continued to log in to their customer devices for as long as the SSH access was opened. I could not understand why Netgear’s login server would be launching brute-force attacks from my ReadyNAS against public IPs on the Internet. I asked this question of the Netgear Engineer to whom my case was assigned (the case was still open), but he assured me that was not Netgear that was doing this brute-force SSH login attempts. Back then, I had no proof that the attacks were coming from my ReadyNAS - it was just a hunch. I did kill the SSH access to my ReadyNAS from the outside on that day, though.
However, tonight I have clear proof that the ReadyNAS is trying to scan multiple addresses on the Internet, attempting to connect on port 22 (SSH). I really need someone’s help on this. I may have exposed my ReadyNAS to the Internet and that got it compromised. I just need help from Netgear to get to the bottom of this. Currently, I disconnected my Netgear from the network, so I’ve lost all the services that it was providing. I tried to create an access list in the Cisco router to deny all traffic from the ReadyNAS to the Internet and log that traffic, but as soon as I applied the access list to the Cisco router’s interface, my Cisco router crashed. That just shows how much traffic is being generated by the ReadyNAS to the Internet.
I think this is a serous problem, and I need help. My ReadyNAS is still under warranty, but I am appealing to Netgear here to notice this post and expedite help. Going through the support portal takes months, and the tickets get closed for no reason, and I just cannot go through it now. This requires serous escalation ASAP.
Please HELP!
Today my public IP was quarantined again by Time Warner. When I called them, they told me that another sysadmin complained about my public IP trying to brute force the root password on their server. This time it got my attention (partly because I work from home and I need Internet, so I can’t have this happening again). Additionally, this time Time Warner threatened to disconnect my account to “protect themselves” from the liability.
So, I decided to change my router’s public IP address, thinking that someone may be spoofing my IP, and the attack really does not come from within my network. As soon as I changed the MAC address on the router’s WAN interface and acquired a new IP, I decided to clear the NAT table to get rid of the connections that could be hung due to my public IP having just changed. Once I cleared the NAT table, I issued the “show ip nat translations” command in the Cisco router and saw this:
tcp 174.98.157.x:37546 192.168.200.30:37546 198.61.172.84:22 198.61.172.84:22
tcp 174.98.157.x:37546 192.168.200.30:37546 198.61.173.118:22 198.61.173.118:22
tcp 174.98.157.x:37547 192.168.200.30:37547 198.61.173.134:22 198.61.173.134:22
tcp 174.98.157.x:37548 192.168.200.30:37548 198.61.173.211:22 198.61.173.211:22
tcp 174.98.157.x:37552 192.168.200.30:37552 198.61.167.35:22 198.61.167.35:22
tcp 174.98.157.x:37552 192.168.200.30:37552 198.61.176.11:22 198.61.176.11:22
tcp 174.98.157.x:37556 192.168.200.30:37556 198.61.169.190:22 198.61.169.190:22
tcp 174.98.157.x:37556 192.168.200.30:37556 198.61.176.144:22 198.61.176.144:22
tcp 174.98.157.x:37559 192.168.200.30:37559 198.61.175.172:22 198.61.175.172:22
tcp 174.98.157.x:37562 192.168.200.30:37562 198.61.169.61:22 198.61.169.61:22
tcp 174.98.157.x:37563 192.168.200.30:37563 198.61.172.72:22 198.61.172.72:22
tcp 174.98.157.x:37565 192.168.200.30:37565 198.61.172.54:22 198.61.172.54:22
tcp 174.98.157.x:37567 192.168.200.30:37567 198.61.173.200:22 198.61.173.200:22
tcp 174.98.157.x:37570 192.168.200.30:37570 198.61.175.119:22 198.61.175.119:22
tcp 174.98.157.x:37572 192.168.200.30:37572 198.61.175.236:22 198.61.175.236:22
tcp 174.98.157.x:37581 192.168.200.30:37581 198.61.176.14:22 198.61.176.14:22
tcp 174.98.157.x:37584 192.168.200.30:37584 198.61.168.226:22 198.61.168.226:22
tcp 174.98.157.x:37584 192.168.200.30:37584 198.61.169.5:22 198.61.169.5:22
tcp 174.98.157.x:37589 192.168.200.30:37589 198.61.175.197:22 198.61.175.197:22
tcp 174.98.157.x:37589 192.168.200.30:37589 198.61.176.147:22 198.61.176.147:22
tcp 174.98.157.x:37590 192.168.200.30:37590 198.61.169.86:22 198.61.169.86:22
tcp 174.98.157.x:37594 192.168.200.30:37594 198.61.176.172:22 198.61.176.172:22
tcp 174.98.157.x:37595 192.168.200.30:37595 198.61.173.111:22 198.61.173.111:22
tcp 174.98.157.x:37599 192.168.200.30:37599 198.61.171.119:22 198.61.171.119:22
tcp 174.98.157.x:37599 192.168.200.30:37599 198.61.173.166:22 198.61.173.166:22
tcp 174.98.157.x:37611 192.168.200.30:37611 198.61.173.114:22 198.61.173.114:22
tcp 174.98.157.x:37616 192.168.200.30:37616 198.61.171.31:22 198.61.171.31:22
tcp 174.98.157.x:37627 192.168.200.30:37627 198.61.176.11:22 198.61.176.11:22
tcp 174.98.157.x:37632 192.168.200.30:37632 198.61.167.35:22 198.61.167.35:22
tcp 174.98.157.x:37632 192.168.200.30:37632 198.61.176.223:22 198.61.176.223:22
tcp 174.98.157.x:37634 192.168.200.30:37634 198.61.169.190:22 198.61.169.190:22
tcp 174.98.157.x:37635 192.168.200.30:37635 198.61.175.232:22 198.61.175.232:22
tcp 174.98.157.x:37638 192.168.200.30:37638 198.61.171.168:22 198.61.171.168:22
tcp 174.98.157.x:37642 192.168.200.30:37642 198.61.172.54:22 198.61.172.54:22
tcp 174.98.157.x:37647 192.168.200.30:37647 198.61.171.168:22 198.61.171.168:22
tcp 174.98.157.x:37647 192.168.200.30:37647 198.61.175.172:22 198.61.175.172:22
tcp 174.98.157.x:37648 192.168.200.30:37648 198.61.175.119:22 198.61.175.119:22
tcp 174.98.157.7:37651 192.168.200.30:37651 198.61.173.222:22 198.61.173.222:22
This is just a small excerpt. There were literally hundreds of fresh NAT rules with random public IP addresses and destination port 22 (which is SSH). The reason I’m posting this here is because the inside source IP (192.168.200.30) is my ReadyNAS Pro Business.
So, it appears that the ReadyNAS is scanning hundreds (and probably thousands) of IPs on the Internet trying to establish a connection on port 22 (SSH).
The following output is from the log of the server belonging to the guy who complained to Time Warner about my public IP attacking his server on December 2, 2012. This log was emailed to me by Time Warner today.
id=0
euid=0 tty=ssh ruser= rhost=cpe-174-098-137-x.triad.res.rr.com user=root
Dec 2 12:39:20 us-dads sshd[23552]: Failed password for root from 174.98.137.x port 43391 ssh2
Dec 2 12:39:20 us-dads sshd[23553]: Received disconnect from 174.98.137.x: 11: Bye Bye
Dec 2 12:39:21 us-dads sshd[23554]: pam_unix(sshd:auth): authentication failure; logname= uid=0
euid=0 tty=ssh ruser= rhost=cpe-174-098-137-042.triad.res.rr.com user=root
Dec 2 12:39:23 us-dads sshd[23554]: Failed password for root from 174.98.137.x port 43683 ssh2
Dec 2 12:39:23 us-dads sshd[23555]: Received disconnect from 174.98.137.x: 11: Bye Bye
Dec 2 12:39:24 us-dads sshd[23556]: pam_unix(sshd:auth): authentication failure; logname= uid=0
euid=0 tty=ssh ruser= rhost=cpe-174-098-137-042.triad.res.rr.com user=root
Dec 2 12:39:26 us-dads sshd[23556]: Failed password for root from 174.98.137.x port 43949 ssh2
Dec 2 12:39:26 us-dads sshd[23557]: Received disconnect from 174.98.137.x: 11: Bye Bye
The 174.98.137.x IP address is the public IP that my Cisco router had before me getting a new IP (174.98.157.x) today.
Finally, below is an excerpt from the log that was emailed to me by the person who complained about my IP trying to brute force the user login into one of his servers back in early November, 2012:
Nov 11 13:00:42 198.15.118.135 sshd[68261]: Did not receive identification string from 174.98.137.x
Nov 12 07:35:14 198.15.118.135 sshd[27345]: Invalid user admin from 174.98.137.x
Nov 12 07:35:21 198.15.118.135 sshd[27347]: Invalid user miquelfi from 174.98.137.x
Nov 12 07:35:35 198.15.118.135 sshd[27353]: Invalid user admin from 174.98.137.x
Nov 12 07:35:56 198.15.118.135 sshd[27365]: Invalid user admin from 174.98.137.x
Nov 12 07:36:17 198.15.118.135 sshd[27367]: Invalid user sunil from 174.98.137.x
Nov 12 12:01:02 198.15.118.135 sshd[42892]: Invalid user fax from 174.98.137.x
Nov 12 12:01:03 198.15.118.135 sshd[42894]: Invalid user pgsl from 174.98.137.x
Nov 12 12:01:04 198.15.118.135 sshd[42896]: Invalid user postgres from 174.98.137.x
Nov 12 12:01:06 198.15.118.135 sshd[42898]: Invalid user postgres from 174.98.137.x
Nov 12 12:01:08 198.15.118.135 sshd[42902]: Invalid user raimundo from 174.98.137.x
Nov 12 12:01:09 198.15.118.135 sshd[42904]: Invalid user joan from 174.98.137.x
Nov 12 12:01:10 198.15.118.135 sshd[42906]: Invalid user johan from 174.98.137.x
Nov 12 12:01:11 198.15.118.135 sshd[42908]: Invalid user sebastian from 174.98.137.x
Nov 12 12:01:12 198.15.118.135 sshd[42910]: Invalid user agate from 174.98.137.x
Nov 12 12:01:13 198.15.118.135 sshd[42912]: Invalid user administrator from 174.98.137.x
Nov 12 12:01:15 198.15.118.135 sshd[42916]: Invalid user alexandre from 174.98.137.x
Nov 12 12:01:16 198.15.118.135 sshd[42918]: Invalid user joseluis from 174.98.137.x
Nov 12 12:01:18 198.15.118.135 sshd[42920]: Invalid user ppazmino from 174.98.137.x
Nov 12 12:01:19 198.15.118.135 sshd[42922]: Invalid user utilidades from 174.98.137.x
Nov 12 12:01:20 198.15.118.135 sshd[42924]: Invalid user utilized from 174.98.137.x
Nov 12 12:01:21 198.15.118.135 sshd[42926]: Invalid user ams telecom from 174.98.137.x
Nov 12 12:01:22 198.15.118.135 sshd[42928]: Invalid user dedlogistica from 174.98.137.x
Nov 12 12:01:23 198.15.118.135 sshd[42930]: Invalid user dsantiago from 174.98.137.x
Nov 12 12:01:24 198.15.118.135 sshd[42932]: Invalid user marcia from 174.98.137.x
Nov 12 12:01:28 198.15.118.135 sshd[42934]: Invalid user consultoria from 174.98.137.x
Nov 12 12:01:30 198.15.118.135 sshd[42936]: Invalid user primaveras from 174.98.137.x
Nov 12 12:01:35 198.15.118.135 sshd[42938]: Invalid user salvatore from 174.98.137.x
Nov 12 12:01:36 198.15.118.135 sshd[42940]: Invalid user commercials from 174.98.137.x
Nov 12 12:01:37 198.15.118.135 sshd[42942]: Invalid user cart as from 174.98.137.x
This attack lasted for over 40 minutes with hundreds of user names tried.
Back in June of 2012, my ReadyNAS started misbehaving. It would become unresponsive once every two to three weeks, and I had to power cycle it with the power button in order to bring it back online. I contacted Netgear support and they worked with me for several months to determine what the problem was. The case # is 19196769. Netgear asked me to provide SSH access to the ReadyNAS for them and even asked me to give them the root password, which I pasted in the ticket notes. Later, it appeared that the root password was not required for them to have access to the RadyNAS, but they had asked for it, and I gave it to them. Additionally, I kept the SSH access open for them for several months. My suspicion is that my ReadyNAS was somehow compromised because of this SSH access being open for several months. I killed it in November after I had the first incident with Time Warner quarantining my IP and when I saw the log with my IP trying to SSH to a server in Europe with various user names. Back then I suspected this brute-force attack was launched from my ReadyNAS because I saw that there was a login registered from a Netgear IP around the time when the attack was reported. There was no reason for Netgear to log in to my ReadyNAS on November 12 (because all the troubleshooting of my original problem had been finished), so I suspected that it was their automated login server that continued to log in to their customer devices for as long as the SSH access was opened. I could not understand why Netgear’s login server would be launching brute-force attacks from my ReadyNAS against public IPs on the Internet. I asked this question of the Netgear Engineer to whom my case was assigned (the case was still open), but he assured me that was not Netgear that was doing this brute-force SSH login attempts. Back then, I had no proof that the attacks were coming from my ReadyNAS - it was just a hunch. I did kill the SSH access to my ReadyNAS from the outside on that day, though.
However, tonight I have clear proof that the ReadyNAS is trying to scan multiple addresses on the Internet, attempting to connect on port 22 (SSH). I really need someone’s help on this. I may have exposed my ReadyNAS to the Internet and that got it compromised. I just need help from Netgear to get to the bottom of this. Currently, I disconnected my Netgear from the network, so I’ve lost all the services that it was providing. I tried to create an access list in the Cisco router to deny all traffic from the ReadyNAS to the Internet and log that traffic, but as soon as I applied the access list to the Cisco router’s interface, my Cisco router crashed. That just shows how much traffic is being generated by the ReadyNAS to the Internet.
I think this is a serous problem, and I need help. My ReadyNAS is still under warranty, but I am appealing to Netgear here to notice this post and expedite help. Going through the support portal takes months, and the tickets get closed for no reason, and I just cannot go through it now. This requires serous escalation ASAP.
Please HELP!
25 Replies
Replies have been turned off for this discussion
- One issue is that things like history of firmwares installed on the unit since last factory default, changes to partition tables on the unit, changes in SMART values etc. are recorded on the OS partition. If you wipe that you lose a lot of valuable information for troubleshooting issues and if support has to look at the system it may mislead them as to what firmware you last did a factory default on which could lead to them misdiagnosing an issue.
While chirpa is no longer at NetGear, he would be well aware of their opinions on things like this, though over time of course their opinions could change. chirpa wrote: The cisco user, did you ever via SSH change the default shell for them? Normal users don't get bash access by default, so FTP guy would be limited to FTP. May have been a ProFTPd exploit somehow that got them escalated privileges. If a shell was set for that user, likely a bruteforce or something let them in. FTP is not secure, sends password in plain text, not hard to sniff it.
Yes, I did change the default shell for the “cisco” user because some of the Cisco gear I have must use sftp to back up its configs. The password was very very rudimentary for this user, so it would not be very hard to guess it. However, I cannot get root privileges when I ssh into the ReadyNAS with this username. When I try “sudo -i” or “sudo su -i”, I get the following error message:
cisco is not in the sudoers file. This incident will be reported.
So, how would they have exploited this username?- So, now that I’ve backed up all of my data, I need to have a plan of how to get rid of this trojan or whatever this is. I have an option of factory-defaulting my ReadyNAS and then restoring data from the backup. However, the problem I’m facing is that when you back up various ReadyNAS shares to a USB drive, using the FrontView backup jobs, all folders originally located in the root of each share are dumped to the root of the USB drive.
For example, let’s assume I have three shares on the ReadyNAS with each of them having three folders in the root:
Share1/Folder_A,
Share1/Folder_B
Share1/Folder_C
Share2/Folder_D
Share2/Folder_E
Share2/Folder_F
Share3/Folder_G
Share3/Folder_H
Share3/Folder_I
I created three backup jobs:
Backup_Share_1_to_USB
Backup_Share_2_to_USB
Backup_Share_3_to_USB
After the backup jobs have completed, I get the following folder structure on the USB drive:
/Folder_A
/Folder_B
/Folder_C
/Folder_D
/Folder_E
/Folder_F
/Folder_G
/Folder_H
/Folder_I
I need a better way of restoring data to the ReadyNAS so that the process of placing folders in the respective shares in automated. I cannot manually move every folder to its share - that will take way too much time.
What I’d like to know is how to use the “Config Backup” feature in FrontView, and specifically the “Data Volumes” option on the “Config Backup” page. The “Data Volumes option has the following description:
Data Volumes - Save the files and folders in the data volumes. This is useful for transferring folder trees and default share contents. It is limited to a combined total of 50MB.
There’s a way to back up “Data Volumes” and then to restore “Data Volumes”. So, how do I integrate this option into my data restore plan?
Thanks! chirpa wrote: # apt-get update; apt-get install chkrootkit; chkrootkit; #paste the output
I suggest backing up data, factory default, copy data back. Consider the OS compromised and don't trust it.
Chirpa,
I’ve done what you suggested and here’s the output of the “chkrootkit” command:
ProServer:/# chkrootkit
ROOTDIR is `/'
Checking `amd'... not found
Checking `basename'... not infected
Checking `biff'... not found
Checking `chfn'... not infected
Checking `chsh'... not infected
Checking `cron'... not infected
Checking `crontab'... not infected
Checking `date'... not infected
Checking `du'... not infected
Checking `dirname'... not infected
Checking `echo'... not infected
Checking `egrep'... not infected
Checking `env'... not infected
Checking `find'... not infected
Checking `fingerd'... not found
Checking `gpm'... not found
Checking `grep'... not infected
Checking `hdparm'... not infected
Checking `su'... not infected
Checking `ifconfig'... not infected
Checking `inetd'... not infected
Checking `inetdconf'... not infected
Checking `identd'... not found
Checking `init'... not infected
Checking `killall'... not infected
Checking `ldsopreload'... not infected
Checking `login'... not infected
Checking `ls'... not infected
Checking `lsof'... not found
Checking `mail'... not found
Checking `mingetty'... not found
Checking `netstat'... not infected
Checking `named'... not found
Checking `passwd'... not infected
Checking `pidof'... not infected
Checking `pop2'... not found
Checking `pop3'... not found
Checking `ps'... not infected
Checking `pstree'... not infected
Checking `rpcinfo'... not infected
Checking `rlogind'... not found
Checking `rshd'... not found
Checking `slogin'... not infected
Checking `sendmail'... not infected
Checking `sshd'... not infected
Checking `syslogd'... not infected
Checking `tar'... not infected
Checking `tcpd'... not infected
Checking `tcpdump'... not infected
Checking `top'... not infected
Checking `telnetd'... not found
Checking `timed'... not found
Checking `traceroute'... not found
Checking `vdir'... not infected
Checking `w'... not infected
Checking `write'... /usr/bin/strings: 'write': No such file
/bin/ls: cannot access write: No such file or directory
not infected
Checking `aliens'... no suspect files
Searching for sniffer's logs, it may take a while... nothing found
Searching for HiDrootkit's default dir... nothing found
Searching for t0rn's default files and dirs... nothing found
Searching for t0rn's v8 defaults... nothing found
Searching for Lion Worm default files and dirs... nothing found
Searching for RSHA's default files and dir... nothing found
Searching for RH-Sharpe's default files... nothing found
Searching for Ambient's rootkit (ark) default files and dirs... nothing found
Searching for suspicious files and dirs, it may take a while...
/usr/lib/perl/5.8.8/auto/ReadyNAS/.packlist
/lib/init/rw/.mdadm
/lib/init/rw/.mdadm
Searching for LPD Worm files and dirs... nothing found
Searching for Ramen Worm files and dirs... nothing found
Searching for Maniac files and dirs... nothing found
Searching for RK17 files and dirs... nothing found
Searching for Ducoci rootkit... nothing found
Searching for Adore Worm... nothing found
Searching for ShitC Worm... nothing found
Searching for Omega Worm... nothing found
Searching for Sadmind/IIS Worm... nothing found
Searching for MonKit... nothing found
Searching for Showtee... nothing found
Searching for OpticKit... nothing found
Searching for T.R.K... nothing found
Searching for Mithra... nothing found
Searching for OBSD rk v1... nothing found
Searching for LOC rootkit... nothing found
Searching for Romanian rootkit... nothing found
Searching for Suckit rootkit... nothing found
Searching for Volc rootkit... nothing found
Searching for Gold2 rootkit... nothing found
Searching for TC2 Worm default files and dirs... nothing found
Searching for Anonoying rootkit default files and dirs... nothing found
Searching for ZK rootkit default files and dirs... nothing found
Searching for ShKit rootkit default files and dirs... nothing found
Searching for AjaKit rootkit default files and dirs... nothing found
Searching for zaRwT rootkit default files and dirs... nothing found
Searching for Madalin rootkit default files... nothing found
Searching for Fu rootkit default files... nothing found
Searching for ESRK rootkit default files... nothing found
Searching for rootedoor... nothing found
Searching for ENYELKM rootkit default files... nothing found
Searching for anomalies in shell history files... nothing found
Checking `asp'... not infected
Checking `bindshell'... not infected
Checking `lkm'... chkproc: nothing detected
Checking `rexedcs'... not found
Checking `sniffer'... lo: not promisc and no packet sniffer sockets
eth0: not promisc and no packet sniffer sockets
eth1: not promisc and no packet sniffer sockets
Checking `w55808'... not infected
Checking `wted'... chkwtmp: nothing deleted
Checking `scalper'... not infected
Checking `slapper'... not infected
Checking `z2'... chklastlog: nothing deleted
But, I had to open my firewall to allow the ReadyNAS to connect to the Internet to get “apt-get” updates, and as soon as I did that, I saw a hundred or so new NAT translation rules pop up in my Cisco router with the destination port of 22 and random IPs. The source IP was my ReadyNAS. So, whatever it is that infected my ReadyNAS cannot be found by “chkrootkit”.- As an alternative to how to get rid of the worm/trojan/exploit/whatever that’s infected my ReadyNAS:
From the thread referenced earlier here, I’d like to get confirmation that this method would work:
1. Backup your system configuration using Frontview
2. Enable Root SSH, log in as root
3. umount -r /c (remount the data partition as read-only)
4. rm -rf /* (delete everything you can. this will attempt to destroy your data along with everything else, but if the partition was remounted as read-only, it won’t be able to).
5. power down the unit
6.force a firmware reinstall using the paperclip method described here: http://www.readynas.com/kb/faq/boot/how_do_i_use_the_boot_menu
(optional) restore your system configuration
This seems to be an easier way than wiping everything out and then having to restore all of my files form the USB backup. Would this method work?
I’ve made the backup, so in case this doesn’t work, I can always do the factory default and then start moving all of my files back to the ReadyNAS (please see my question about how to move folders into shares a few posts above).
Thanks! - I would give it a try. Like you said, if it fails, you've got a backup. Would save a lot of time on restoring files if it does work.
- I have done it, and it did work for me.
To be thorough I would manually rm -rf all addons and any other non-data/share related folders on the /c volume.
I think ls -la /c should list all hidden folders and shares.
du -hsc /c/* is also useful to see what folders are using how much space. - clamav can be installed via apt-get, might be worth while after reinstall to scan the data volume for any attempts at injecting malware, where clients could possibly get infected. Or you could do a network virus scan from a PC to the NAS volume.
- As a hypothetical...
Is it possible to create an OS partition on a blank disk (perhaps the same size), and then replace the OS partition on the real data drives? (perhaps manually copying selected configuration files)????
Just wondering. The risk with this approach is that you can't be sure you've gotten it all. There still could be some trap door left open that could be exploited later. - as another note, regarding the '(optional) restore your system configuration' noted above,
Since it seems highly possible your system was compromised, and although I don't know if there is anything in the config files that would weaken or allow the system to be re-hacked, I would suggest you forgo re-importing the settings and just set up the nas from scratch. I've done it many times and it doesn't really take long, unless maybe you have dozens of shares and/or users/groups to remake. But even then, I personally would rather re-do it myself than have a potentially compromised config re-imported to a clean system.
@stephenb, I don't think so but my linux-fu is still level n00b.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
