Environment Variables are insecure and transferred to new repository owners

Deployment
, ,
1

I used a github to transfer the repository to the new owner. We test a build and watched it deploy. The Travis CI console showed a successful deploy. The problem is, it deployed to my AWS account using my AWS credentials. The environment variables had been transferred to a third party and were no longer in my control, any fix?

2

The threat model/paradigm in this particular situation isn’t really an attacker (if an attacker gets into your GitHub account, it’s essentially all over anyway).

The main issue at hand is regarding the secrets. The trivial fix is to wipe secure env vars then change hands. Seems like the most logical and safe thing to do, and unfortunately in this case this didn’t happen.

I’d recommend setting the value from the Travis CLI just to rule everything out travis env set GH_TOKEN <your token>.

If you want to be secret about that token even in your terminal:

read -s NEW_TRAVIS_PASS <enter your password in the empty void> 
cd <directory containing the cloned repo> travis env set 
GH_TOKEN $NEW_TRAVIS_PASS unset NEW_TRAVIS_PASS

I’ve seen a similar case, where people don’t clear their env vars before transferring over repositories to new owners. This is the equivalent of wiping a phone before giving it to a new owner, etc. For good measure you can delete the logs with the --delete flag, which optionally takes a reason as an argument:

travis logs --delete DANGER ZONE: Do you really want to delete the build log for travis-
ci/travis.rb#559.1? |no| yes deleting log for travis-ci/travis.rb#559.1 $ travis logs 1.7 --delete "contained c
onfidential data" --force deleting log for travis-ci/travis.rb#1.7

Another way of doing this is using the Travis API via:

curl -X DELETE \
  -H "Travis-API-Version: 3" \
  -H "Authorization: token xxxxxxxxxxxx" \
  https://api.travis-ci.com/job/{job.id}/log

In turn:

DELETE
/job/{job.id}/log

Make sure on their end it’s encrypted again, should look like this:

image
image1560×514 74.7 KB

Travis CI uses a public-key/private-key security system, also known as asymmetric cryptography, to encode and decode sensitive data. When I encrypt env vars in Travis, under the covers, the Travis CLI tool used the public key to do the encryption.

However, decryption can only take place within the Travis CI runtime environment, because only Travis CI has access to the private key.

These are all things you must remember when dealing with env vars and are completely relevant to the Travis CI env vars. It’s no different than Docker. I hope this helps and hopefully this gets you out of hot water, and lesson learned.

Montana Mendy
Travis CI Staff

1 Like
3

If your AWS credentials got compromised (let’s be real),
you need to change them, or revoke them if it’s an access token.

2 Likes
4

@native-api,

To say the least. As I stated it’s unfortunate that the env vars were not wiped when the transfer occurred.

1 Like
5

yeah we sorted out problem this morning, thank you for all the help

6

I’m curious as how you got this sorted out? - Was it something technical, or a human variable?