Welcome to our blog.

Learnings from past SaaS companies

In a typical SaaS startup you’ll find the dev team under heavy pressure to deliver new features. You usually have competitors who might be better funded, you’ll have the sales team asking for one last feature to close the deal, the customer support team asking for a bugfix. It can be hard to prioritize security unless a bigger enterprise customer demands it or your board imposes it from the top.

In most startups, you might not have a full range of tech profiles at your disposal: you might not have a full-time product manager yet, you probably don’t have a full-time head of security on your development team. A dev team under pressure to deliver will be forced to cut a lot of corners, even when it comes to security.

I have been the CTO of 3 early-stage SaaS startups. (Teamleader, Officient & Futureproofed) Below I’ve outlined my learnings from those past SaaS company experiences.

Avoid reinventing the wheel

A great example: don’t build a login system with passwords. Yes, you could build it in a few days, but the cost to maintain it and add advanced protection features in the future will be very high. Consider using a login via Single-sign on such as Gmail or use a service such as Auth0.com. You’ll not only have a smoother, more feature-rich login experience, but you also won’t have to worry about a whole class of login-related security aspects (brute-forcing, leaked user credentials in 3rd party services, avoiding and detecting account takeover attacks, validating email addresses, logging...).

In the end, if you pick the right vendor, you’re not just reducing your attack surface, you’re also winning time that can be spent on more valuable features.

Other great examples that could save you weeks or months are:

• Don’t store credit cards, use something like Stripe or Mollie or Chargebee
• Don’t run complex software like MySQL or PostgreSQL or ElasticSearch yourself. Use managed cloud services such as RDS.
• Don’t build your own logging systems. Use systems like Sentry or Papertrail (and don’t log any sensitive data there)
• Don’t run your own email (SMTP) servers, use a managed service like Sendgrid or Mailgun
• Don’t build websocket servers, use managed services such as Pusher.com
• Don’t build your own featureflagging system, use a service such as Launchdarkly
• Don’t build your own calendar integration, use a tool like cronofy.com
• When building integrations in general, check for Unified APIs in that space such as Apideck.

Invest some time in a crisis communication setup

Make sure you have tools set up such as a chat application to talk to your customers, or better, a managed status page or Twitter account where you can communicate problems. In case something bad happens it’s a great practice to enable the rest of your company to communicate to your customers while you focus on fixing the problem during a crisis.

Add global guardrails

You’re probably reviewing Pull Requests from your developers, great! It’s quite a task to review them for maintainability, performance, functionality. Do you have time to also review them for security? For sure you’ll be able to cover some risks, but it’s nice to be able to sideline some risks by adding some guardrails and global configuration.

Sometimes, you can get lucky and global fixes exist for specific issues.

• If you use nodeJS and don’t like thinking about prototype pollution, you should freeze the prototype to disable this class of attacks app-wide. Aikido can automatically build a Pull Request that does this for you.
• If you use SQL and are afraid of SQL injection attacks (you should be), you can use a WAF (like AWS WAF) or RASP (like Datadog’s app security) for app-wide protection
• If you’re discovering a lot of XSS attacks, you can likely remove a large part of them by introducing a very strict CSP policy in the browser.
• If you’re doing a lot of outbound requests based on customer input, you might be vulnerable to SSRF attacks. While it might be hard to block this completely, you might mitigate damages by making sure it can’t lead to something worse (such as an IMDSv1 attack on IAM credentials in AWS). Aikido monitors this in your AWS cloud by default.
• When dealing with object storage, avoiding specific types of functions such as Pickle, XML, (un)serialize in Java and PHP,.. and instead going for simple storage options such as JSON can avoid a lot of typical exploits related to unsafe unserialization. Aikido monitors for these kinds of functions in your codebase by default.
• If you use a CDN or caching mechanisms, use separate domains for your static assets with separate CDN configurations to avoid all kinds of cache poisoning attacks (ChatGPT ran into this trap recently)

Educate your developers with this one simple trick

There’s an easy hack (pun intended) you can implement in your processes. One quick question to ask the dev team during sprint planning:

How can the functionality we’re building get hacked? (& how can we prevent that from happening)

While the dev team may not anticipate every potential abuse scenario, this methodology is dead simple to scale. It’s a small extra step that encourages developers check in on security considerations before undertaking any development work.

Assign priorities to different parts of your codebase

Not everything will be as big of a target for hackers. Key components they love to target are :

• Payment systems, wallets, credit systems
• Functionality that connects to expensive APIs like SMS, voip (think Twilio)
• Password reset, login systems, user invites
• Export features such as PDF, Excel,.. exports that might perform risky operations
• Anything related to file, image uploads
• Features that do outbound requests by design, such as webhooks
• Any kind of feature that sends email, especially with personalized content

PS: Aikido can help you focus on only the top repositories in your startup’s universe by assigning risks levels to each codebase.

Don’t forget about the human aspect

As CTO in a small startup, you’re usually also the one in charge of operational security. Provide your team with the means to secure their accounts. Make sure they use hardware Yubikeys or software apps for 2FA and if possible, enforce it. Tools like Gmail allow enforcing this. It’s a great first line of defense against phishing attacks.

Staying up-to-date with security practices is hard

Learning about new kinds of attacks on software is hard. It’s hard enough to follow up on updates to the languages that you use (Python, Node, Go,..) or OS patching or popular exploits in open-source packages. Specific attack become more popular over time so it pays off to follow the trends. For example, after noticing an uptick in subdomain takeover attacks last year, Aikido introduced a subdomain takeover monitoring tool to prevent that risk and to automate the practice of monitoring these DNS records.

Automate away

At my previous companies, we would try to get to a next level of security by having a security person build a calendar with recurring security tasks. Do an access-review for all apps every quarter. Do a leaked-secrets scan on the code every couple of week, clean up the open source package CVEs every Friday, do a SAST scan every so often, verify the DNS records for subdomain takeovers every month,... The output of these tasks was hard to triage and make actionable for developers. Worse, when this person left the company it was hard for anyone else to pick up these tasks because they required a lot of specific knowledge.

This is where the idea of Aikido started growing. We needed a solution to automates all of the above, filter out the noise and get the tasks in front of your developers in Slack or Jira.

Start scanning your code & cloud with Aikido today. Sign up over here and start scanning for free.

Preventing total cloud takeover via SSRF attacks

This is the story of an attacker who gained access to a startup’s Amazon S3 buckets, environment variables, and various internal API secrets, all via a simple form that sends an email. Even though this is a true story, I’m keeping the startup’s name a secret.

How they got in

It all starts with a PHP application sending out an email. To load some of the fancy images to the email as attachments, the application needs to download them. In PHP this is easy. You use the function file_get_contents and that is where the fun begins.

Of course, some of the user input for this email was not fully checked or HTML-encoded, and thus a user could include an image such as <img src=’evil.com’/>. Now, in theory, this is not that too bad, but sadly this PHP function is very powerful and can do much more than load images over the internet. It can also read local files and more importantly: files over the local network instead of the Internet.

Instead of evil.com, the attacker entered a special local URL. You can use this URL to get the IAM credentials linked to the role of the AWS EC2 server you're running with a simple GET request.

<img src=’http://169.254.169.254/latest/meta-data/'>

The result was that the attacker got an email that included the IAM credentials for the EC2 server in an attachment in the mailbox. Those keys give the attacker the ability to impersonate that server when talking to various AWS services. It all goes downhill from there...

Why is this even possible in the first place?

The system that loads these IAM keys is called IMDSv1 and Amazon released a new version in 2019 called IMDSv2. With IMDSv2, you need to send a PUT request with a special header to get your IAM credentials. That means a simple GET-based URL loading function like file_get_contents can no longer cause that much damage.

It’s unclear what the adoption of IMDSv2 is as of 2023, but it’s clear Amazon is still taking measures to increase its adoption and we’re seeing IMDSv1 still being used in the wild.

The compromise of the IAM keys leads to further compromises: The S3 buckets could be listed and their contents read. To make matters worse, one of the S3 buckets contained a cloudformation template, which contained sensitive environment variables (eg Sendgrid API keys).

How do I defend my cloud infrastructure against this?

Now, what could be done to prevent this total loss of data? Your developers could be extra careful and take care to use an allowlist for the URLs they pass on to file_get_contents. They could even verify that the content they receive is an image if they are expecting an image. The reality is however that these kinds of mistakes are hard to avoid as a developer.

It would be a lot better to ensure your infrastructure has extra defenses against these attacks. Our new integration with AWS inside of Aikido security will alert you if your cloud does not actively take any of the following measures. Each of these measures on its own would have stopped this particular attack, but we recommend implementing all of them. Use our free trial account to see if your cloud is already defended against these threats. See how Aikdido protects your app against vulnerabilities here.

Steps to take:

1. Migrate your existing IMDSv1 EC2 nodes to use IMDSv2
2. Don’t store any secrets at all in the environment of your webservers or in cloudformation templates. Use a tool such as AWS Secrets Manager to load the secrets at run-time.
3. When assigning IAM roles to your EC2 servers, make sure they have extra side conditions such as restricting them to be usable only from within your local AWS Network (your VPC). The example below allows your server to read from S3, but only if the EC2 server is communicating via a specific VPC endpoint. That’s only possible from within your network, so the attacker wouldn’t have been able to get to the S3 buckets from his local machine.

{
"Version": "2012-10-17",
"Statement": [
        {
"Sid": "rule-example",
"Effect": "Allow",
"Action": "s3:getObject",
"Resource": "arn:aws:s3:::bucketname/*",
"Condition": {
"StringEquals": {
"aws:SourceVpce": "vpce-1s0d54f8e1f5e4fe"
                }
            }
        }
    ]
}

About “The Kill Chain”

The Kill Chain is a series of real-life stories of attackers getting to the crown jewels of software companies by chaining multiple vulnerabilities. Written by Willem Delbare, leveraging his ten years of experience in building & supporting SaaS startups as a CTO. The tales come directly from Willem’s network and all really happened.

Belgian SaaS startup Aikido Security has raised €2 million in pre-seed funding from renowned angel investors who support its mission to simplify software security for developers.

In recent years, there has been a shift in the software industry towards “shift left” development, which has pushed the responsibility for security ever more toward developers. Unfortunately, current software security platforms are hard to use for developers, wasting loads of their time. Aikido Security has been founded to meet this challenge.

The pre-seed round is fortunate to have the support of an array of qualified (angel) investors. Syndicate One, Pieterjan Bouten (Showpad), Louis Jonckheere (Showpad), Christophe Morbee (Besox), Mathias Geeroms (OTA Insight) have all decided to join in. Aikido Security is lucky to be able to count on their support & expertise.

“Software security tools have made my life as a CTO harder”

says Aikido Security founder & CTO Willem Delbare. “I’ve tested so many of them and they all suffer from the same problems. They overload you with false positives, spam you with notifications, and make triaging hard. I’ve found it to be very exhausting. We’ve decided to fix this.”

The team is made up of experienced entrepreneurs who have built successful products in various industries before coming together at Aikido Security. The founding team consists of Willem Delbare (Teamleader, Officient), Roeland Delrue (Showpad, Officient), Amber Rucker (Veriff, Cloudbees) & Felix Garriau (nexxworks, AREA42).

Aikido has recently completed the alpha version of its product which it is actively testing with early adopter customers. The funding allows the company to grow the team and make the product feature complete, next to growing its customer base.

About Aikido Security

Aikido Security is a developer-first software security platform. We scan your source code & cloud to show you which vulnerabilities are actually important to solve. Triaging is sped up by massively reducing false-positives and making CVEs human-readable. Aikido makes it simple to keep your product secure and gives you back time to do what you do best: writing code.