SecDevOps: Protecting Terraform state file

Terraform is one of the most used tools to deploy Infrastructure as a Service or IaaS for short, but we have to manage it in a secure way.

Some developers add the terraform state file terraform.tfstate into the repository to share it among developers easily, which turns out to be a very bad idea as in the terraform state file also credentials and private keys are stored. So, if somebody could access to the repository, it will have automatically access to our infrastructure too!

Instead of storing the terraform state file locally or publicly in the repository. We should store it remotely in a secure way to be consistent with the changes we made.

Terraform supports many remote backends to store the state file remotely: AWS S3 Bucket, Google Cloud GS, artifactory, etc. So we can store it remotely to keep consistency among team members and we define later four options to store securely any sensitive data such as private keys, private IPs addresses or passwords.

To avoid any future mistake and do not upload those files into the repository, better to add terraform.tfstate and terraform.tfvars to your .gitignore file.

# Add to .gitignore
terraform.tfstate
terraform.tfvars

Also init.tf must be password safe.

We have several options for passing safely variables to terraform containing the passwords and private keys.

Option 1: We can use environment variables to pass values, although keep in mind that can be stored in your .bash_history file.

export TF_VAR_token="abcdefgihjklmnpq"

Option 2: Use an encrypted local file with terraform variables
Option 3: Use Hashicorp Vault
Option 4: Store it in Mac OS Keychain

Be aware to store the artifactory password also in the secrets manager!

Summing up… deploy fast but don’t forget to stay safe 🙂

How to deploy Docker images on Google Cloud Run

We can easily run dockerized apps on Google Cloud using still beta Google Cloud Run.

One thing to keep in mind is to specify $PORT variable inside our Dockerfile, by default Cloud Run always uses PORT 8080, but for portability reasons we will specify it as a variable:

# Dockerfile for Google Cloud Run
FROM php:apache
ARG PORT
ENV PORT=${PORT:-8080}
COPY . /var/www/html/
RUN sed -i 's/80/8080/g' /etc/apache2/sites-available/000-default.conf /etc/apache2/ports.conf
RUN mv "$PHP_INI_DIR/php.ini-development" "$PHP_INI_DIR/php.ini"
RUN service apache2 restart
EXPOSE $PORT

So we can deploy and run the docker locally in this way:

$ docker build --tag user/image .
$ PORT=8080 && docker run -e PORT=${PORT} --rm -p 8080:${PORT} -it user/image

Once inside a directory with the Dockerfile and the application just run:

$ gcloud projects create new-project-$RANDOM
$ gcloud config set project $PROJECT_ID
$ gcloud builds submit --tag gcr.io/$PROJECT_ID/image .
$ gcloud config set run/region us-central1
$ gcloud beta run deploy --image gcr.io/$PROJECT_ID/image --platform managed

It takes some minutes but finally gets deployed and dumps where it was deployed, something like https://$IMAGE-xxxxxxxxxx-$ZONE.run.app

Simple and vulnerable NodeJS app prone to Cross-Site Scripting (XSS) deployment with Google Cloud App Engine

I wrote a little script in node.js for a hands-on lab to test Cross-Site Scriptings (XSS).

You can download it from my github: https://github.com/spinfoo/nodexss

To deploy in Google Cloud App Engine:

$ git clone https://github.com/spinfoo/nodexss.git
$ gcloud init
$ gcloud projects create xss-lab$RANDOM
$ gcloud config set project xss-lab$RANDOM
$ gcloud projects describe xss-lab$RANDOM
$ gcloud app create --project=xss-lab$RANDOM
$ gcloud app deploy
$ gcloud app logs tail -s default

#Slack built-in support for #RSS feeds

I just discovered that Slack has built-in support for RSS feeds.

It’s a great feature to subscribe all your feeds in a private channel, so you can keep updated and even share your feedback with your team.

For example, to subscribe to Microsoft Security Advisories:

/feed https://technet.microsoft.com/en-us/security/rss/advisory

I will share later my RSS feeds for #cybersecurity

United Airlines Bug Bounty Program

After soooome time for the triaging and patching the reported bug. I was awarded with 50,000 miles for reporting a bug to United Airlines, inside their Bugbounty program.

Decided to donate them to Rotary International charity and use them for the great causes.

Small tool to decode ASP.NET __VIEWSTATE variable when doing webpentests

I just wrote a small tool to easily decode ASP.NET __VIEWSTATE variables without having to install the viewstate module into the system with administrative privileges and be able to decode the variables with a small script using a terminal, without writting python code.

Sometimes when doing webpentesting against a ASP web application is useful a tool like this.

$ ./decoder.py "/wEPDwUKMTU5MTA2ODYwOWRkoCvvBWgUOH7PD446qvEOF6GTCq0="
** ASP.NET __VIEWSTATE decoder **

[*] Decoding __VIEWSTATE:
/wEPDwUKMTU5MTA2ODYwOWRkoCvvBWgUOH7PD446qvEOF6GTCq0=
(('1591068609', None), None)

https://github.com/spinfoo/viewstate-decoder

CVE-2017-12544 Hewlett Packard Enterprise, HP System Management Homepage Software prior to 7.6.1 Cross-site Scripting (XSS)

The HP System Management Homepage (SMH) is a web-based interface that consolidates and simplifies the management of ProLiant and Integrity servers running Microsoft Windows or Linux, or HP 9000 and HP Integrity servers running HP-UX 11i.

https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-hpesbmu03753en_us

Original Advisory: https://www.securityfocus.com/archive/1/541823/30/0/threaded