OT industrial cybersecurity: ModBus protocol

OT stands for Operational Technology, contrary to the IT that is Information Technology. Inside IT we put things such as servers, computers, laptops, smartphones, etc. OT is more focused on more low-level devices that keep factory lines busy, as for instance, a PLC (Programmable Logic Controller) that can control an hydraulic valve or a nuclear plant valve.

One of the most used industrial protocols is ModBus protocol. Contrary to many other propietary protocols, ModBus uses TCP/IP for communications.

Usually ModBus connections use TCP/502 port, however this port is unsecure by default as communications are not encrypted AND any attacker can impersonate a master device to perform unexpected actions.

Guess how many openly available ModBus devices are public on the Internet:

So, first thing to keep in mind is: NEVER expose industrial devices to the Internet if you do not plan that some attacker literally hacks your factory.

Second thing, upgrade your protocol and use TCP/802 instead of default TCP/502 as the first provides encryption.

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

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 馃檪

Indicadores de compromiso del ransomware Emotet / Ryuk

Desde principios de a帽o hay una evoluci贸n del malware Trickbot, llamada Emotet / Ryuk que cifra todos los ficheros de nuestro sistema, pidiendo un rescate en bitcoins para poder recuperarlos, tipo de ataque conocido como ransomware.

Muchas han sido las empresas espa帽olas afectadas: Grupo Prisa, Everis, Prosegur y varios hospitales.

Estos son los enlaces que el ransomware utiliza para bajarse el payload con el malware, actualizad vuestros firewall o reglas del IPS para bloquear cualquier conexi贸n hacia estos servidores web:


Para un an谩lisis forense de c贸mo opera Emotet / Ryuk, ver el siguiente enlace de Crowdstrike y el estudio del CSIRT-CV.

Para entender c贸mo afecta a nivel del sistema y qu茅 ficheros modifica, ver an谩lisis de any.run. C贸mo se puede apreciar en el estudio, el punto de entrada es abrir un fichero Word que ejecuta una macro en Powershell que se descarga el payload con el c贸digo malicioso. A partir de ah铆, el ransomware ataca el sistema actual y busca otros sistemas vulnerables en nuestra red, para propagarse y causar el mayor impacto posible.

A parte de tener todos los sistemas bien actualizados, un buen sistema de copias de seguridad off-site, muy conveniente deshabilitar el WOL (Wake-on LAN) y protocolo de compartici贸n de ficheros SMB, si no est谩n siendo usados activamente.

Al igual que el conocido WannaCry, Ryuk se propaga como un worm dentro de la red afectada a trav茅s de la vulnerabilidad Eternal Blue (CVE-2017-0143) parcheada por la actualizaci贸n de seguridad MS17-010. Por lo que, en caso de no usar el protocolo SMB, es mejor deshabilitarlo en todos los equipos para evitar que el ransomware se propage y afecte a m谩s equipos.

Importance of metric-oriented goals: KPIs vs. OKRs

KPIs (Key Performance Indicators) are a way to measure performance within a project or team. They establish the goal, so afterwards we can compare if we achieved or not. KPIs do not explain how to reach those goals.

On the other hand, OKRs (Objectives and Key Results) are more descriptive in the way that not only establish the objetives for the quarter/year/etc (THE WHAT) but also give detailed statements describing the tasks we’ll do to achieve those objectives (THE HOW).

OKRs have 4 pillars:

  1. Focus and commit to priorities
  2. Align and connect for teamwork
  3. Track for accountability
  4. Stretch for amazing

OKRs are a good method to keep people focused on the most important goals and prevent them to lose focus doing urgent but less important tasks.

In a general way, there are two types of OKR:

  1. Committed OKRs: They should be all completed by the end of the period
  2. Aspirational OKRs: They stretch and force the team to achieve ambitious goals, which we can mark them as successful if we reach around 70% of completion

OKRs should be set quarterly and annually, and only set from 3 to 5 objective to keep a narrow focus and productivity. As Andy Grove said, focus on everything = focus on nothing.

Although there is many hype lately around OKRs, they were invented and used by Andy Grove (Founder and CEO of Intel) in the 80’s and early 90’s! Later on, supported by John Doerr, it was also implemented in several startups like Google, Youtube, Intuit, etc.

Furthermore, Grove and Doerr enforce constant performance review (CFR: Conversation, Feedback, Recognition) instead of the old and conservative annual reviews, which in this fast-paced world are becoming obsolete.

To give some brief examples, based on a sales department of an e-commerce website:

KPI example: Reach USD 100 million revenue in Q3

OKRs example:

Objetive for Q3
Reach USD 100 million revenue in Q3
Key Results
Sign agreements with 130 recognized brands
Increase market share up to 20%
Register 200,000 new users in the website

Ultimately, productivity is linked to clear-defined goals and actions speak stronger than words 馃檪

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
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

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