It's been a year and nine months since Anders Skovsgaard and I decided to do something about the state of automated penetration testing and start working on Heyhack on a gray winter day in Denmark. We spent most of 2022 developing the core of Heyhack's scanning engine from scratch and finally launched the first version on Product Hunt on August 9, 2022. We immediately received a lot of positive feedback from the community and grew to become the #1 Product of the Week, resulting in the induction into the 2022 Product Hunt Hall of Fame. 🥇
Since then, we've been working with companies all around the globe to enhance the security of their web applications and mitigate the risk of data breaches. Our customers range from small one-person startups to some of the largest brands with more than 50,000 employees globally, and working with such a diverse group of organizations has taught us a lot about building a versatile product that serves a wide variety of different security needs.
Over the past year, we've made a bunch of significant improvements to Heyhack, and today, we're announcing the results of all these improvements in the new version of Heyhack—version 2.0. 🎉 In this blog post, I'll go through all of the major advancements that have led us to what's objectively now the world's most advanced automated penetration testing engine for web apps and APIs.
Seamless Authentication
Authentication is always been one of the cornerstones of Heyhack. Anders and I have spent too many hours configuring dynamic application security testing (DAST) tools, trying to get them to log into applications automatically without user interaction. Competing DAST solutions often require that you write funky regular expressions, code your own Selenium scripts, record login flows using Chrome/Firefox plugins, etc. It's tedious, it doesn't scale across multiple applications, and even when doing your very best to set things up correctly, it doesn't work most of the time. 🤷
That's why we've taken a stance in Heyhack. We will never ask customers to jump through weird hoops to get something as basic as authentication set up for their applications. We've taken it upon ourselves to continue the evolution of our authentication module so that it just works as you would expect it to without any configuration whatsoever. We're now at a point where we can handle any authentication flow used by modern web applications—including form-based login pages (both cookies and tokens), passwordless logins, two-factor authentication (with time-based one-time passwords), third-party identity providers (such as Auth0, Google, Microsoft Entra ID, Okta), and more.
The best thing about it? It. Just. Works! 💪
If a login page protects your application, simply provide the usernames and passwords of the test users you would like Heyhack to use for logging in. Yes, that's plural! Heyhack is the only DAST solution out there that handles multiple users out of the box, enabling us to test for advanced issues on Broken Access Control—but more on that later!
Is two-factor authentication enabled on your test users? No sweat! Heyhack supports the Time-Based One-Time Password Algorithm (RFC 6238). To make it even easier to configure 2FA for your users, we've recently updated our UI so you can either upload an image of the QR code containing the shared secret or use your camera to scan it directly. Here's what it looks like in Heyhack.
We're continuously adding features to our authentication module, so stay tuned for more updates. Now, on to the topic of coverage—the bee in our bonnet!
Complete Coverage and Transparency
Not a day goes by without Anders being on a customer call uttering the words: You can't test what you can't see! Being able to crawl and navigate modern web applications is fundamental for any DAST solution to conduct a meaningful test of a given target. A decade ago, before the emergence of single-page applications, many DAST tools did a respectable job of getting around most applications and uncovering most functionality. Today, the story is very different.
Modern web apps built in client-side-heavy frameworks such as React, Vue, or Angular demand a lot more from the DAST tools testing them. The same applies to the next wave of web app frameworks based on WebSockets (such as ASP.NET Core Blazor, Ruby on Rails with Hotwire, Phoenix LiveView in Elixir, etc.). As a DAST tool developer, you can't count on the entire DOM being rendered initially—you must interact, hover over, click on, and trigger every element and event. Most competing solutions out there (including the open-source OWASP Zed Attack Proxy) are based on outdated crawling techniques that prohibit them from finding all the functionality there is to test. This results in tests that end prematurely and, thus, don't provide a reliable overview of the security issues present in the target application.
When Anders and I wrote the first lines of code in Heyhack, we were very aware of this challenge. That's why Heyhack has been built from the ground up without any dependency on legacy testing frameworks. Heyhack is based on the latest version of ChromeDriver (the engine inside Google Chrome), which we have modified extensively to allow us to run in-depth tests that you can't run with Selenium or any other standard testing framework.
Two months ago, we decided to take things up a notch and take our test evidence to a whole new level. Now, after every completed penetration test, Heyhack compiles a complete video of the entire penetration test that lets you review and understand everything that Heyhack has done during the test. You'll see all the pages Heyhack has found, all the elements it's interacted with, all the forms it's submitted, and so on. This provides a very visual look into what's going on under the hood of a penetration test and allows you to get confident about the test results.
Here's a sample video from a penetration test conducted on the OWASP Juice Shop.
Anders has been the chief architect on this project and will soon publish an in-depth blog post describing all the ins and outs of the new video generation feature.
External Attack Surface Management
External attack surface management (EASM) is an emerging category in the world of application security—and rightly so! As companies continue to expose more applications on the Internet, maintaining an overview of all the applications and services developed by the entire organization, hosted in different data centers, and published on different domains is an increasingly daunting task.
You'll often find some interesting insights by simply taking a look at what your company exposes on the Internet. Examples include decommissioned services that were supposed to be shut down, outdated web and SSH servers (such as Apache HTTP Server, nginx, and OpenSSH), open FTP servers (and sometimes even highly vulnerable ones like ProFTPD 1.3.5 with the mod_copy module), dangling DNS records, and much more.
Notably, the issue related to dangling DNS records is very widespread. Almost all larger organizations suffer from this issue, which can have very severe consequences. The problem is fundamentally linked to the use of public cloud providers such as Amazon Web Services, Microsoft Azure, Google Cloud Platform, and others. Often, developers or marketing professionals will set up dev/test servers, marketing campaigns, or other short-lived applications and services. They'll make use of a cloud provider for hosting and get a DNS record (either an A record or a CNAME record) set up from a subdomain on their main corporate domain that points to their newly created server in the cloud.
Everything is fine and dandy until someone realizes that the server isn't needed any longer. Everybody and their grandmother want to reduce their cloud computing bills so that someone might just go ahead and delete the server, releasing its associated IP address or hostname. Now, the problem is that IP addresses and hostnames in the cloud are not owned by the customers using them. AWS, Azure, and GCP will happily reuse these IP addresses and hostnames for other customers, exposing anybody with DNS records pointing to them to subdomain takeover attacks.
A shockingly large proportion of our enterprise customers have been victims of such subdomain takeover attacks without even knowing it. To help them become aware and prevent such attacks from happening in the future, we decided to build Heyhack Recon—a fully automated external attack surface management solution for web applications and services.
Heyhack Recon continuously monitors your domains to uncover exposed subdomains. For every found subdomain, Heyhack will fingerprint its services to examine your exposure and let you know of any immediate issues (such as dangling DNS records and server versions with known vulnerabilities, aka. CVEs). Moreover, Heyhack will look up the owner of the netblocks your services are hosted on to help you gain an overview of the different hosting providers used in your organization.
Here's a snapshot of some of the subdomains exposed on europa.eu:
The best thing about it is that Heyhack Recon comes for free in our Professional and Enterprise plans. While many competing EASM providers charge tens of thousands of dollars for similar services, customers on our Professional and Enterprise plans gain access to this incredibly helpful tool, which underpins any sound application security strategy.
Learn more about how it works on the Heyhack Recon product page.
Broken Access Control
Broken Access Control is the number 1 security risk to web applications, according to the most recent edition of the OWASP Top 10. A shocking 94% of applications in the data foundation underpinning the OWASP Top 10 tested for some form of broken access control. It's a ticking time bomb for many web apps out there—particularly the ones serving and storing sensitive data. (Did anyone say 23andMe? 😰)
Unfortunately, the vast majority of DAST tools are not suited for finding issues related to broken access control in depth. As mentioned above, most competing DAST tools struggle with the basic task of logging into modern applications (and staying logged in). Logging in with two different users is even more challenging but is essential for being able to test common broken access control vulnerabilities (OWASP), including:
- Violation of the principle of least privilege or denial by default, where access should only be granted for particular capabilities, roles, or users but is available to anyone.
- Bypassing access control checks by modifying the URL (parameter tampering or force browsing), internal application state, or the HTML page, or by using an attack tool to modify API requests.
- Permitting viewing or editing someone else's account by providing its unique identifier (insecure direct object references).
- Accessing API with missing access controls for POST, PUT, and DELETE.
- Elevation of privilege. Acting as a user without being logged in or acting as an admin when logged in as a user.
- Metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges or abusing JWT invalidation.
- CORS misconfiguration allows API access from unauthorized/untrusted origins.
- Force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user.
At Heyhack, we take broken access control very seriously, which is why a large part of our test suite is dedicated specifically to testing the types of issues mentioned above. We do it by asking you for the credentials of multiple test users that we can use during the test. We'll first conduct a complete test with the first user. We'll note all the endpoints, records, parameters, and other user-specific data points we found during the test. Then, we'll log out, log in with the second user, and do the same thing. After completing the second test, we'll examine the user-specific data points to see where there's an overlap and where there are some differences.
That produces a list of candidates for potentially vulnerable endpoints that we'll test in depth. In the OWASP Juice Shop, there's an endpoint at the route /api/BasketItems/ that allows users to put items into their baskets. Unfortunately, the code for the route does not check the user's credentials, allowing any user to manipulate the basket of other users—a very severe issue had the Juice Shop been an actual webshop and not just "the most modern and sophisticated insecure web application" designed for security trainings, awareness demos, CTFs and as a guinea pig for security tools. 🐹
When you provide the credentials for multiple test users in an application in Heyhack, we will automatically conduct our broken access control tests. Setting up multiple users is super simple—check out how it's done in the screenshot below.
Improved Tests
Finally, we've continuously improved the test suite that underpins the penetration tests conducted by Heyhack Scan. The web is constantly evolving. New frameworks pop up, new techniques are used, and new types of deployments are leveraged. These are all posing new and ever-changing risks to web applications that developers need to stay aware of to guarantee the security of their applications.
We've improved all areas of our test suite, but particularly, our tests for cross-site scripting issues have been enhanced significantly and now outperform all other DAST tools out there. In a world where 98.8% of all web apps and websites make use of JavaScript, ensuring that your application is resilient against cross-site scripting attacks is absolutely crucial. Even though many modern web development frameworks will help you avoid the pitfalls of rendering user input without proper escaping/sanitization, a large proportion of the thousands of web apps we've tested in Heyhack suffer from cross-site scripting issues.
Just last week, we updated our test suite page, giving a complete overview of all the tests we conduct as part of our automated penetration tests. In addition to running our own proprietary tests to uncover zero-day vulnerabilities in applications, we also run Nuclei by ProjectDiscovery to test for more than 2,000 known web vulnerabilities (registered in the Common Vulnerabilities and Exposures database, aka. CVE).
Keep an eye on our test suite page as we constantly add more tests to it. 👀
So Much More to Come
We're incredibly proud of the advancements we've made over the past year and feel grateful for all the insightful customer dialogs we've had ever since we launched Heyhack Scan.
We've got a lot more interesting things in the pipeline and will keep you updated on a more regular basis going forward. We look forward to sharing more in the future! 😃
