• Services
  • Blog
  • Knowledge Base
  • Contact
our services
  • Application Penetration Testing

    • Username Enumeration
    • iOS Frida Objection Pentesting Cheat Sheet
    • URL Redirection – Attack and Defense
    • Jailbreaking iOS 13 with unc0ver
    • X-Runtime Header Timing Attacks
    • wkhtmltopdf File Inclusion Vulnerability
    • API Mass Assignment Vulnerability
    • Web Server TRACE Enabled
  • AWS Pentesting

    • Protecting S3 buckets using IAM and KMS
    • Misconfigured S3 Bucket
    • S3 Storage Does Not Require Authentication
  • DevOps Security

    • Securing Travis CI
  • Encryption

    • TLS 1.0 Initialization Vector Implementation Information Disclosure Vulnerability
    • OpenSSL ‘ChangeCipherSpec’ (CCS) MiTM Vulnerability
    • Null Ciphers Supported
    • ‘Export Ciphers’ Enabled
  • Network Penetration Testing

    • .NET Handler Enumeration
    • TLS_FALLBACK_SCSV Not Supported
    • PHP Easter Eggs Enabled
    • MySQL Multiple Vulnerabilities
    • Debian Predictable Random Number Generator Weakness
    • Cisco IKE Fragmentation Vulnerability
  • Pentesting Fundamentals

    • Essential Wireshark Skills for Pentesting
    • Testing Cookie Based Session Management
  • Windows Hardening

    • Resolving “Windows NetBIOS / SMB Remote Host Information Disclosure” (2020)
DevOps Security

Securing Travis CI

our services

Overview

Travis CI is critical service used for many modern CI/CD pipelines. It is used to automate testing and deployments which allows developer to deploy faster ever before. But Travis must be granted full access to code repositories and most often is granted with AWS or other cloud access tokens as well to enable code to be pushed to its environment. Because of this Travis can easily become a weak point of security unless properly configured.

Securing Credentials

It may be tempting to store access tokens and secret tokens in the .travis.yml ‘deploy’ directive, but this would expose cloud credentials to anyone with source code access. To mitigate this, Travis allows sensitive keys to be encrypted with a private key stored by Travis. Travis will generate a private key unique to each repository, allowing users to encrypt access tokens which are only valid for that repo. The keys cannot be used to access cloud infrastructure and cannot be used with other repositories to deploy code.

The following is an example where we encrypt our AWS secret token so Travis can deploy code to Elastic Beanstalk after testing:

  1. Install the Travis cli

    sudo apt install ruby ruby-dev
    sudo gem install travis
    
  2. Authenticate with your Github credentials (these are only sent to Github)

    travis login --pro
     Username: myusername
     Password for myusername: ********************
    
  3. Change directory to a local clone of your Git repo and use ‘travis pubkey’ to confirm Travis can access the repo’s public key.

    $ cd myrepo
    $ travis pubkey
    Public key for myAccount/myrepo:
    
    ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDPCS1c64ok4DfqNohEUAAoyD1U5QO6TLGjQ[...]
    
  4. Encrypt your secret access token (Travis will use the public key above)

    $ travis encrypt "my_secret_token"
    Please add the following to your .travis.yml file:
    
      secure: "CsptKIYpdGKS0d6FBrDmya40E9QA0waRfA0AxsvARSplYYuZkSj45jBFPY [...]"
    
  5. Place the encrypted token in the .travis.yml under the ‘deploy’ directive

    deploy: 
      provider: elasticbeanstalk 
      access_key_id: AKXRJXRNXDEXQASXHOXA 
      secret_access_key: secure: CsptKIYpdGKS0d6FBrDmya40E9QA0waRfA0AxsvARSplYYuZkSj45jBFPY [...]

Travis should now be able to automatically and securely deploy to AWS environments without user interaction. Keep in mind the following other tips:

  1. If secret tokens have already been committed to repositories, the keys should be deleted and regenerated immediately. Once plain text keys are committed to Github they should be considered compromised.
  2. The secret tokens used should be provisioned with minimal permissions and policies for your environment, do not use root tokens.
  3. It’s a good practice to schedule new tokens to be generated on a regular basis.
← wkhtmltopdf File Inclusion Vulnerability
X-Runtime Header Timing Attacks →
  • Services
  • Blog
  • Knowledge Base
  • Contact
Looking for a better
penetration test?

Make an appointment with an expert today

    Request a meeting invite? (EDT)

    Contact ASAP3:00 PM Today4:00 PM Today1:00 PM Tomorrow3:00 PM TomorrowOther / Just Send Info