[HN Gopher] Launch HN: Escape (YC W23) - Discover and secure all...
___________________________________________________________________
Launch HN: Escape (YC W23) - Discover and secure all your APIs
Hey HN! We're Tristan and Antoine, co-founders of Escape
(https://escape.tech). We use AI inspired by chess to help security
engineers and developers discover and secure APIs created by their
organizations. Here is our demo: https://youtu.be/qcCaegVElTY
Typical modern large orgs have hundreds if not thousands of APIs,
and many of those handle sensitive data or are critical to business
operations. The development of those APIs is distributed across
different development teams that don't always have knowledge of API
security best practices. API source codes are updated frequently,
making it easy for new, easily exploitable security vulnerabilities
to be introduced in production environments (think the 2018 FB 50M
accounts data leak). APIs make up 80% of global web traffic, and
this share is growing. The responsibility for securing APIs is
usually given to the organization's security engineers, not the API
developers, which makes sense because they're the ones who know how
to secure things. But in practice, it is almost an impossible job
because the security engineers have no way to track everything the
developers are exposing online, and usually, there's nobody to tell
them! And when they do find out, they lack the right tooling for
achieving it. This is a huge risk for organizations, a pain and
personal risk for security engineers, and a great technical
challenge. Working as a software engineer a few years back, I
faced a data scare: a pharmaceutical client's data was compromised
due to a NoSQL injection. In this case the damage ended up
controlled, but it led to the nightmarish thought of waking up one
day with all the data from the applications gone, simply because
cybercriminals exploited a security issue. When looking for
solutions that allowed developers to ensure what they released in
production was secure, we couldn't find anything particularly good.
Security scanning tools like OWASP ZAP had been designed for people
with penetration testing backgrounds. Code scanning tools were only
finding the low-hanging fruit at the cost of many false positives,
and ended up resembling security-oriented linters, turning the
entire IDE red for minimal value. It felt like none of the existing
security tools were built with real engineers in mind. When I met
Antoine, who had previously been a security engineer at NATO and
Apple, we decided to tackle this issue together and create a modern
security tool that would appeal to both developers and security
people. It needed to be fast, easy to set up yet configurable, have
outstanding support for securing APIs, and find what was relevant
with a low false positive rate. The first step was to show
security engineers and developers what APIs they had to secure. We
needed to find an easy way to discover any organization's exposed
and internal APIs. To discover all APIs, we crafted a system that
extracts all the API routes the organization exposes by scanning
its domains, frontend websites, and SPAs. It then enriches this
data by connecting to code repositories, API gateways, and API
development tools to create a full list of all the exposed
endpoints and the sensitivity of the data they handle. Other
testing tools do not provide an inventory of all the API routes
exposed by an organization, but as we mentioned above, the biggest
problem security engineers face is often just finding out what it
is they need to test! Then, we needed to provide security
engineers and developers with a list of security issues in their
APIs. Since APIs act as a business model layer, most of the
critical security issues lie in the business processes underlying
APIs. In security, issues obtained from breaking business processes
are called Broken Object Level Authorization (BOLA), Broken
Function Level Authorization (BFLA), and Broken Object Property
Level Authorization (BOPLA). To find them, we knew we couldn't
rely on traditional techniques like fuzzing. We needed to find a
way to model the Business Process underlying the API and attempt to
break it. Doing research on this topic, we discovered that
modeling API business processes in a similar way to board games,
like Chess or Go, worked surprisingly well. The underlying reason
is simple: a board game is a state machine on which you can execute
actions that must respect rules to change the game's state. Think
about moving the pieces in a chess game, each piece has its
specific moves, and their position on the board represents the
state. APIs are similar: they have a database, which represents
the internal state, and API routes, which represent the actions you
can run on the state. Of course, most APIs are more complex than a
chess game because they have much more routes than there are chess
pieces. In mathematics, we would say that the action space is much
larger. But the models are similar enough for us to try applying
alpha-beta, Monte-Carlo Search Three, and more advanced Machine
Learning techniques that have proven to work well in the context of
large action space games like Go. Those were the foundational
ideas behind our in-house algorithm, Feedback-Driven API
Exploration (FDAE), which automatically identifies the underlying
business processes and generates sequences of API requests
especially aimed at breaking them, uncovering potential security
flaws and data leaks. FDAE starts by ingesting the list of routes
and parameters in an API. It first identifies the routes leading to
sensitive data, like PII or financial information, and the
parameters that have the most chances of being vulnerable to
various kinds of injections and attacks. Often, those routes
require parameters like UUIDs or domain-specific values. That's
where traditional security scanners fall short: they often fuzz
randomly the parameters hoping to find some low-hanging fruit
injection, but end up blocked at the data validation layer. FDAE
is smarter. If it detects that the route /user/:uuid might be
sensible, it will first look at all the other routes in the API and
try to find one that returns a valid user UUID. Once it gets the
valid user UUID, it will use it to trigger the /user/:uuid route
and try to exploit it in many different ways. If there are no
existing users in the database, but there is a route to create one,
Escape's FDAE will even be able to create a user, get its UUID, and
then attempt exploiting the routes that require a user UUID. This
process, very similar to what human penetration testers and bug
hunters do, allows Escape to do extensive and deep testing of any
API and business processes. It's specifically good at finding many
access control bugs like tenant isolation problems, complex multi-
step injections, and request forgeries. To give a specific
example, imagine you're building an e-commerce application, Escape
can detect cases where users can bypass payment steps or modify
input parameters in the request to access other user's orders or
private information. You can find a more detailed explanation of
how Feedback Driven API Exploration works with graphics here:
https://escape.tech/blog/feedback-driven-api-exploration/ Escape's
entire scanning process takes minutes. It was very important to us,
as former developers, to seamlessly integrate API testing in CI/CD
pipelines and quickly implement relevant fixes. To verify that it
was scalable, we scanned all public APIs on the internet and
produced research reports on their quality: the State of GraphQL
Security (https://26857953.fs1.hubspotusercontent-
eu1.net/hubfs/268579...), and the State of Public APIs
(https://apirank.dev/state-of-public-api-2023/). Apart from
discovering and testing APIs in minutes, we wanted to make Escape
actionable. Pinpointing a problem is one thing, but then how to fix
it? Most dynamic scanners give vague remediation instructions.
Escape actually generates code snippets to help developers. We
offer a few monthly and yearly subscription plans based on the
number of APIs and developers in the org, with a free 7 days trial.
The pricing is accessible in the app during a trial period. Since
our product is highly technical, we wanted to make sure that users
can explore our features, evaluate what Escape does, and understand
its value before making a decision. Users can see pricing details
at a point in their trial journey where it makes the most sense,
aligning with their understanding of the product. You can try us
without a credit card at https://escape.tech. Our main SaaS
product is closed source, but we publish many open source packages
for security and developers on https://github.com/Escape-
Technologies/ , some of them being widely used like GraphQL Armor
(https://github.com/Escape-Technologies/graphql-armor/) The number
and complexity of APIs are constantly growing, and we're continuing
to learn every day, so we would greatly appreciate and are eager
for your feedback (no matter how big or small)! Thanks!
Author : glimow
Score : 74 points
Date : 2024-02-01 13:38 UTC (9 hours ago)
| neon_me wrote:
| Something went wrong. Please use a professional email address.
|
| :))) whats wrong with my not-professional email address?
| glimow wrote:
| Hello, we limited the registration to personal email because
| too many people were trying to scan APIs that didn't belong to
| them.
|
| Mind you that you can also use your personal GitHub account to
| register because we noticed people are way less likely to do
| risky stuff with their Github account than with a personal
| email :)
| mderazon wrote:
| Looks like it's limited for Graphql ?
| shinymanu wrote:
| They started with GraphQL but after a while they also developed
| a security scanner for REST APIs that use OpenAPIs or
| Swagger[1].
|
| [1] https://escape.tech/blog/rest-security-testing/
| glimow wrote:
| Thank you, yes, we originally supported GraphQL only and
| released REST scanning support a few months ago. We plan to
| support all types of APIs ultimately.
| FinnKuhn wrote:
| The amount of newly created accounts under this post praising
| this product reeks of botting...
|
| edit: some of those comments have now disappeared. Make of that
| what you want.
| ramraj07 wrote:
| Have noticed under several launch HN posts - often other batch
| mates I think. Not sure how to feel about it tbh.
| dang wrote:
| It's against the rules and if you scroll down
| https://news.ycombinator.com/yli.html you'll notice it's in
| bold text--for a reason! Unfortunately it's hard to get the
| message across, because people who aren't avid HN users have
| no idea of the conventions here, and there are other
| platforms where it's considered fine.
|
| I've emailed the founders to tell their
| friends/teammates/etc. not to do this.
| sbuccini wrote:
| Voting ring detection for thee and not for me
| dang wrote:
| Launch HNs for YC startups get placed on HN's front page
| automatically - this is one of the things that HN gives back
| to YC in exchange for funding it. It's in the FAQ:
| https://news.ycombinator.com/newsfaq.html.
|
| Since the purpose of voting rings is to try to get on the
| front page, that construct doesn't really apply here, unless
| you want to call "automatic placement" a "ring".
| dang wrote:
| Regular HN users have flagged the comments, since obviously
| they're against the convention here. I've emailed the founders
| to ask them to call off their friends/teammates/etc.
|
| People who don't know HN's rules often try to "help" in this
| way. I try to tell everyone that it doesn't help, it hurts! but
| it's hard to get the word out.
|
| (Edit: forgot to mention that the comments disappeared because
| HN users flagged them enough to make them [dead]. You can see
| [dead] comments if you want to, by turning on 'showdead' in
| your profile. That's also in the FAQ:
| https://news.ycombinator.com/newsfaq.html)
| glimow wrote:
| Hello, although we know HN's rules, some of our users don't.
| They just tried to help without telling us.
|
| I guess we can be proud that they are our users and wanted to
| help. There was no intent to break HN's rules. We apologize for
| that happening, and we have told them about the rules so it
| doesn't happen again.
| motoxpro wrote:
| Seems amazing. Is this going to be an enterprise only product?
| Don't see a pricing page.
| glimow wrote:
| Hello motoxpro, the pricing page is accessible inside the
| product during the free trial.
|
| Although, by nature, the security market is mostly enterprise,
| we do have plans for startups and SMB as well. Happy to have
| your feedback on our pricing btw, always something hard to get
| right.
| motoxpro wrote:
| Thanks! Is that something that you would ever consider
| putting on the main site, or adding some hints to show that
| that is possible once you sign up? Or maybe that you could
| share here?
|
| I understand the potential market, however, as a startup, I
| probably wouldn't (and won't) sign up because I have been
| burned too many times when companies pivot to enterprise
| pricing only (i.e. Hasura) and it doesn't give me much
| confidence there would be a reason for you to continue
| supporting those plans since it's not the focus of the
| company based on not even having pricing on the home page.
|
| Not a critique, just some feedback :)
| btown wrote:
| Who watches the watchers?
|
| If I understand the product correctly, you're suggesting
| customers opt into letting an LLM pentest their testing systems,
| and allowing that LLM to generate and carry out plans of attack.
|
| Imagine a recurring revenue business that keeps tokens for user
| credit cards on file, and then a dev naively gives the CI
| infrastructure an ability to call out/proxy some calls to
| production in a privileged way, and then Escape finds a way to
| break out of CI and charge cards on the production system. Of
| course, this is a massive security issue in and of itself, but at
| a certain point, a human pentester would know "holy ** I should
| stop what I'm doing right now." How do we know that Escape won't
| keep fuzzing and fuzzing and exacerbate the situation, causing
| real-world impact to customers?
|
| There's probably a philosophical take on this - that security by
| obscurity is no security at all, and that threat actors will be
| every bit as good at this as Escape's technology is. But for any
| business that's not really a dedicated target for actors (say,
| only gets drive-by script kiddies that are easily fended off by
| keeping software up to date) using Escape might be increasing
| their risk of a breach that is meaningful to their customers, by
| inviting the scrutiny of a well-funded LLM, with a laser focus
| only on your specific business, that doesn't know when to stop.
| glimow wrote:
| Hello btown, you are indeed raising legitimate questions here.
|
| You are right in the sense that using automated security
| testing tools in production creates a risk. But there are
| workarounds:
|
| 1) Most of Escape's security scans happen on staging or pre-
| prod environments, where there is little risk of breaking
| something critical or finding real customer data.
|
| 2) We have designed a specific scan mode for production APIs,
| that is made with safety in mind. It will not attempt the
| riskiest attack scenarios and, thus will be safe for production
| use at the cost of scanning depth.
|
| You can chose a scan mode when adding a new application for
| testing in Escape. So far, most of our users use both modes,
| one for the production environment and one for the development
| environment, to spot bugs early.
|
| No user ever had problems with the production scanning mode.
|
| By the way, the core algorithm powering Escape is more a graph
| traversal algorithm than LLMs. We do use a small, self-hosted
| LLM for specific inference tasks, but everything is made in-
| house, and we don't use OpenAI or any other inference API.
|
| Hope that helps!
| lazyasciiart wrote:
| How does your product compare to Akita?
| https://www.akitasoftware.com/
| nprateem wrote:
| I know you're writing for a technical audience and not investors,
| but if you can't grab my attention without a wall of text, sorry,
| tldr.
| glimow wrote:
| The << Launch HN >> posts, like this one, follow quite standard
| community guidelines that includes having a detailed
| description of how the product works to bring value to
| technical people from the HN community.
|
| Of course, for investors, we would have written things
| differently, but we are not looking to raise money at the
| moment.
|
| Hope that makes it more clear!
| tptacek wrote:
| You're not the audience for this post.
| fierro wrote:
| congrats! Really crisp idea, excited to try this out
| glimow wrote:
| Thank you! Hope you will like it
| HorizonXP wrote:
| I think you guys are on the right track and this is a problem we
| are struggling with at my client.
|
| I'll test it out with them and see what they think. I will say
| that we were originally exploring Bright, but we had to rely on
| telling them what APIs and endpoints to hit, and they wanted to
| embed an engineer with us to help us onboard their product.
|
| We wanted something simple that we could pay money for, have it
| discover all of our endpoints, pentest, and return a report.
|
| 1) please move pricing onto main site 2) please consider
| deploying on Azure Marketplace
|
| The fact you're including GraphQL is a big positive too.
| glimow wrote:
| Thank you for the positive vibes.
|
| We try to make our product as straightforward as possible. It's
| a long journey for such technical topic but it gets better
| everyday.
|
| And we listen to feedback. I'll take a look at Azure
| Marketplace.
| lazyasciiart wrote:
| What's the reason this repo is archived? It looks useful.
| https://github.com/Escape-Technologies/py-multiauth
| glimow wrote:
| Hey there, so py-multiauth is a great project that we love, but
| it didn't get enough attention from the community for us to
| afford to maintain it outside of our main codebase.
|
| Since then, we have completely revamped it to create py-
| multiauth v2 that supports basically all form of authentication
| as you can see in the docs
| https://docs.escape.tech/authentication/
|
| py-multiauth v2 is not open source for now, but our eng team
| might be ok to open source it if there is interest from the
| community
___________________________________________________________________
(page generated 2024-02-01 23:00 UTC)