Dependencies: It’s not just your code you need to secure.

The EQUIFAX USA event of 2017 put into the spotlight an underconsidered aspect of software security: It’s not just our code that we need to secure. The facts of the case are widely known, but, its cause? Not so much. Little is said about the fact that this leak would not have taken place if the developers of the EQUIFAX application had upgraded their Apache Struts web framework to a more secure version.

We developers are not creating applications based only on our code. We rely on servers, programming languages, frameworks, libraries (wheels, gems, JARs…) and we need to secure all that, even that code we copy-paste from Stack Overflow.

When we create applications, we are not just writing code, we are building a house with Lego blocks, and our code is just a part of that house. In fact, our code is on the top of that house. All that other stuff we depend on, is underneath, it’s our software’s foundations, and if it is not secured, our house will fall apart, just like EQUIFAX’s did.

One notable thing to mention in this issue is the fact that this kind of vulnerability is listed in OWASP Top 10 2017.

OWASP Top 10 2017 entry.

Project support

The good news is that some developers have begun to take notice on the issue. There are projects available that aim to help developers to take care of dependency security even before their code reaches the CI/CD (Continuous Integration/Continuous Delivery) server.

These tools are continuously updated, based on security data obtained from CVE (Common Vulnerabilities and Exposures) data and developer reports, and can be used in CI/CD servers as well.

Here are some of them:

OWASP Dependency Check (Java, multilanguage)

The main reference when it comes to dependency security checking is

OWASP’s dependency checking tool

Read more

GDPR Compliance: How Continuous Vulnerability Scanning is Key

Even months after interest in GDPR compliance peaked, some companies are struggling to make sure they comply with this new set of regulations aimed at protecting the privacy and security of European citizens. The regulation applies to businesses anywhere as long as their users are in the EU, and with the highest penalties potentially reaching the millions of euros, they’re right to worry.

Take the case of British Airways for example. On September 6th, 2018 the airline announced that it had suffered a breach that affected around 380,000 users, and that part of the stolen data included personal and payment information.

Now, although we don’t know the fine that will be levied on British Airways, under GDPR a violation such as this one may lead to a fine of 20 million or up to 4% of a company’s annual turnover in the previous year (whichever is higher), which for BA could reach about £489 million (US$633 million) based on 2017 figures.

A similar case is that of Marriott. In November 2018 they announced that they had been a victim of an attack that compromised the data of 500 million users. Marriott’s annual turnover in 2017 was US$22.9 billion.

More recently, Google has been the target of a 50 million fine in France for failing to provide enough information to users about its data consent policies and not giving them enough control over how their information is used.

Often when we read about GDPR, it may sound like it’s all about notifications (letting users know what kind of data the company is using and how it will be used and notifying them of security breaches in a timely fashion), but if these cases show us anything it’s that companies will be under scrutiny not only for how they use their customer’s data but also how they protect it. This is where early detection and prevention of security vulnerabilities is key.

Article 32 of the GDPR provides that businesses must

“implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including […] as appropriate: […] a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.”

Read more

These are the 10 web vulnerabilities most frequently found by Hackmetrix

After having run thousands of scans on Hackmetrix we can finally say we officially know the 10 most common vulnerabilities we’ve found across every site we scanned.

The purpose of the article is to be a source of information for users who have found any of these on their sites, to encourage site owners to check their online properties for any of these, and to provide a line or two on how to fix them wherever possible.

If you’re not sure how to check your site for any of the vulnerabilities mentioned here, then a free Hackmetrix account could be a good start. It only takes a minute to sign up and you’ll have your first report in just a couple hours.

As time goes by we’ll also be expanding on each of these with more in-depth guides explaining each of these issues and how to solve them.

Let’s get to it!

  1. Absence of Anti-CSRF Tokens – Risk: Low

Our most frequently found vulnerability is (luckily?) not a high risk one. Cross Site Request Forgery (CSRF), is a type of attack that tricks a user’s browser into performing an unwanted action on a trusted site where the user is authenticated, and it works even if the user doesn’t have that site open at the time.

This works because of the trusting nature of web browsers. A browser doesn’t check to see if an outgoing request is going out from a specific domain, and so in a similar way you might be able to tweet or check an Instagram post from an external website, a more ill-meaning site could use an open session in one of those sites to post, or take some other action, on your account without you ever noticing.

For example, let’s say you regularly check Twitter and so your session on that site remains open (an open session is what makes it possible for you to open a new tab and go to and see your feed without having to log in every time). While you’re checking your friends’ tweets you click on a very enticing link to a questionnaire to find out what kind of fast food you are. Irresistible.

That questionnaire though, holds hidden and nefarious intentions, and as soon as you click a button on it to see the results it takes advantage of your open session on Twitter to tweet on your behalf a link to itself and follow a bunch of unknown accounts. This without you ever consenting, or finding out until you look at your own feed.

Now take that and imagine it being used on, instead of Twitter, a bank account. CSRF is a common problem, and one of the ways it can be prevented is by using =&2=&.

Using an anti-CSRF token would mean that each time a website loads it includes a unique string of characters, then when a request is made (in our example that would be each time you try perform some action on Twitter), the server expects to receive that same token back, and if it doesn’t then it will refuse to perform the action requested. You can see then why it’s highly recommended to implement an Anti-CSRF Token, and why not doing so is considered a vulnerability.

=&3=&=&4=& Read more

10 Security Tips to Protect your Business

Most CTOs today have a software engineering background but have only limited knowledge about securing applications at scale.

The goal of this post is to be an easy to understand resource get you started on the path to a more secure app. This is a guide that early stage CTOs (and anyone else) can use to harden their security, without it feeling like a chore.

Restrict internal services by IP addresses

Connections to your infra and non-public properties (hosted CIs, Admin interfaces, databases etc.) should only be accessible through a bounce host (VPC, VPN etc.)

Network segmentation / Segment the network

Limit the network’s visibility. Split your network into subnetworks, each one being a network segment.

Take control of who accesses the network by implementing VLANs. Your network structure is only visible locally, so the attacker will find themselves with the task of understanding the non-visible network infrastructure, that’s one more step for them and a little more peace of mind for you.

This measure allows the business to limit the effects of issues or failures generated in a network segment, in this way, the segment could be put on quarantine avoiding the damage propagation to the other segments.

Node hardening / Harden your nodes

Avoid pivoting to give some additional security to your network segments.

“Will do!”, you say, “but what the heck is pivoting?”

Well, it’s the technique of jumping from one network segment to another to gain a broader attack range. So, how can I be safe from this? Hardening is a common network technique where we give special attention to device configurations.

This usually means to update default credentials and remove unnecessary software, logins, and services. In the following list we will give you some basic tasks that are hardening activities.

  • Use strong passwords
  • Close key ports that you don’t use(Ex: ssh)
  • Update security patches
  • Encrypt, but don’t try to reinvent the wheel
  • Implement virtual machines or containers techs

Guide to Linux Hardening

Guide to Windows Hardening

Implement a firewall

Firewalls are beautiful programs that could be the difference between a server working correctly, and a server being down.

The firewall’s job is to protect internal networks from unauthorized external access and attack attempts.

Have your firewall carefully configured, they are really useful, but if you don’t take the time to customize it, it could just be a waste of valuable resources.

Cloudflare Getting Started

AWS WAF guide

Run it unprivileged

If an attacker successfully hacks your application, having your services running as a restricted-user will force them to scale privileges, making it harder for the attacker to take over the host and/or to bounce to other services.

Privileged users are called =&5=& on Unix systems, and =&6=& or =&7=& on Windows systems.

These users have complete control of the system, so it’s really important leave them alone and only use them on those cases where they are specifically and inevitably necessary.

A common scenario is to find the databases running as root/system or under a unique user for more than one database, which brings us to another weakness.

If an attacker gains access to one of database, they automatically will have access to all the rest. So, don’t use privileged users and create one user and password for each database and service you have.

Make sure all your critical services are secured

As a company you rely on a variety of services like Google Apps, Slack, WordPress etc. Don’t settle for the security defaults of these tools, they are some of the first things the attackers try and they can be an easy attack vector if not configured properly.

There are different tools to generate and save credentials like KeePass or LastPass, they use a master key to access the information, or in their mobile versions, allow you to use touch ID.

Also, make sure you update everything regularly, this is not only because you’ll get a nicer interface, but in the majority of cases updates are released to fix vulnerabilities and add new functionality, which could include new security measures.

So, if you have any default credentials, update them! And, if you have any software, service, or platform with a pending update, update it!


How to harden your Google Apps

Hardening WordPress

Backup, then backup again

Backup all your critical assets. Ensure that you attempt to restore your backups frequently so you can guarantee that they’re working as intended.

Don’t do it only when you remember to do it, nor with a year between each backup. Be regular, and do it with reasonable periods of time. Don’t take unnecessary risks. S3 is a very cheap and effective way to backup your assets:

Guide to backing up files on Amazon S3

Guide to backup on Digital Ocean

Guide to backup on Azure through Resource Manager

Enforce a password policy



Please, don’t act surprised if I just guessed at least one of your passwords.

Read more

How we check your security status

What do we do?

If you are reading this, you’ve probably already heard about us, and in this post I do not want to talk about =&0=& , instead I’d like to talk about =&1=& with almost no information other than your domain name.

To understand =&2=& it’s important to understand that the process of a Penetration Test follows a series of flexible rules, the same rules that we apply in our methodology of Automatic Security Analysis. You will find detailed information in this post about this process and how we use these steps to automate the security analysis process.

=&3=& Read more

How to whitelist IPs on AWS, DigitalOcean, and Cloudflare

One of the first things that we ask from our users after they create their Hackmetrix account is to whitelist our IP addresses in their firewall rules.

Because Hackmetrix simulates attacks on your site or app in order to report vulnerabilities and show you how to fix them, it works best if your firewall lets us do our thing.

Now, since we’ve gotten a few questions as to how and why do this, we wrote this article to explain what whitelisting means, and the step by step instructions to do it in 3 of the most popular services for developers: AWS, DigitalOcean, and Cloudflare.

Let’s dive in!

What is the Whitelisting?

First things first:=&1=&.

A firewall whitelist is a set of configurations that let you specify which IPs can have access to your platform, allowing even suspicious behavior, but keeping your security configurations with any other addresses that are not on that whitelist.
=&2=& Read more

Big Oops: Google+ to shut down after leaving up to 500,000 users exposed

  • A bug in the Google+ API left data like name, email address and gender of up to 500,000 users exposed
  • Google patched the issue earlier this year and didn’t find any evidence of the data being misused
  • This is the final nail in the coffin for Google+, which will be shut down by the end of 2019

In the past couple years we’ve seen a few giants either fall under scrutiny for how they’ve handled their user’s personal information –ahem-Facebook!-, or straight up had their user data held for ransom as was the case with Uber.

Now it seems it’s Google’s turn. The search giant left personal information exposed for more than a few users of its Google+ social network. How many users? Up to 500,000.

Oh My God Wow GIF

Luckily, it seems no one took advantage of the exposed data, so we should all be safe.


Read more

Backed by

Hackmetrix startup chile