Someone tried to hack me

Writizzy is barely two weeks old. Last week, I faced my first Black Hat attack. It wasn't a Bug Bounty probe; it was a malicious attempt to delete production data.

This is how I detected and remediated the attack, and why this event cemented my philosophy of 'Pain in the Ass Driven Development' for early-stage products.

White Hat vs. Black Hat

Why am I calling this a black hat attack?

You might say, a hacker is a hacker, regardless of intent.

However, there are nuances to consider.

You have the White Hats, who test your site and then report the vulnerabilities they find.

It's quite common to be contacted by white hats, who also expect some compensation.

However, this remains risky because the legal framework is often unclear, and the researcher could get into trouble.

Therefore, the vast majority of white hats work within legally framed Bug Bounty programs provided by companies. The secondary benefit of these programs is guaranteeing payment for the vulnerabilities found.

Within the white hat category, there is a second group, often referred to as beg bounty. These are often people who have industrialized basic checks on websites, finding often minor flaws, and randomly contact sites hoping for a reward.

And then you have the Black Hats, with many different motivations:

• Data theft: The goal is to resell the information elsewhere.
• Data destruction: Driven by ideology, for fun, or for personal reasons.

It is undoubtedly this last scenario that presented itself to us last week.

The attacker attempted to delete articles specifically from the thomas-sanlis.com blog, and only that one.

Detection

The attack took place on November 7th. I started receiving Sentry alerts regarding inconsistent usage, for example, attempts to delete data that did not belong to the requesting author.

Since the application is a Nuxt SSR application, the client communicates with the backend via an API.

The attacker attempted to directly exploit the API by replacing the identifiers used, which is known as an IDOR (Insecure Direct Object Reference) vulnerability or, more generally, Broken Access Control.

Fortunately, the API performs numerous server-side checks, notably by verifying the session information and its consistency with the received request.

I was able to investigate the traces to find the author and the target.

The author created an account using a disposable email address. These mailboxes are frequently used to avoid leaving a trace. I’ll come back to how to prevent this later.

The target was the blog of Thomas Sanlis.

A bit later, the same person attempted to change their account email to use Thomas's, likely with the goal of logging into his account, given the first attack failed.

Remediation Actions

Writizzy was launched less than 2 weeks ago, so I hadn't yet implemented all the necessary protections. What was in place was enough to fend off the attack—hopefully, it's always hard to be 100% sure. But I knew certain parts needed to be more robust.

I now have an arsenal of actions available:

• Account blocking.
• Temporary blocking for brute force attacks (temporary to prevent an attacker from also blocking all accounts they know are using the site).
• Rate limiting on certain actions and per IP.

I will also likely prohibit the use of disposable emails on the site.

There are two main approaches for this:

• Calling an external API to validate the email (e.g., debounce.io, emailable.com, captainverify.com, etc.).
• Checking against an open-source list yourself. One of the best known seems to be: disposable-email-domains, but this requires a regular and automated update mechanism for the list.

Pain in the Ass Driven Development (PITADD)

This reminded me of a previous company I created. Moderation did not exist until the day one person contacted 1,000 people at once overnight. We created a moderation feature the very next day to prevent it from happening again.

It is always a question of timing. It's difficult to anticipate everything, and it's expensive, too. So there is always a balance between cost and risk.

This balance changes depending on the context—if you work in the medical field, for example.

But you cannot build a bunker on Day 1 for a non-critical site. Of course, a necessary minimum is required and some basic stuff are non-negotiable, especially regarding data protection. But the rest comes as risks increase, such as when the company grows.

Here is my framework for risk arbitration (examples):

• Data theft is critical. It must be anticipated on Day 1.
• Data loss is important, but can be mitigated by backups. Implementation can be postponed a bit.
• Spam is an annoyance. It can be handled manually as long as the volume remains low.

etc...

I categorize this arbitration as: Pain in the Ass Driven Development.

This applies just as much to security, design, architecture, and so on.

It's simply not possible to have the same level of maturity as a 10,000-person company from the start.

You have to wait until it hurts, or until it risks hurting very badly.

The trade-off is that you have to be responsive and have the right measurement tools in place (monitoring, alerts, logs, etc.), otherwise it's not a strategy, it's negligence.