Offensive Security Researcher & Quantum Cryptography Analyst

Exploitation Phase: Targeting CMS, GitHub, and Subdomain Takeovers

Abdul Wahab Junaid
Exploitation Phase: Targeting CMS, GitHub, and Subdomain Takeovers

According to a survey performed by W3Techs, 62% of the internet is run on a Content Management System (CMS), and a staggering 39.1% is run on WordPress. This means that when assessing potential targets, the vast majority of sites encountered will be utilizing a CMS framework. This high prevalence offers a crucial starting point for vulnerability researchers and penetration testers, as a single, widespread exploit can have a massive impact.

I. Targeting Content Management Systems (CMS)

WordPress: The Internet’s Foundation

As of right now, over a quarter (25%) of the internet is built using WordPress. This is vital information because it means a single, effective exploit has the potential to impact a large portion of a target’s assets. There are, in fact, hundreds of exploits and misconfigurations impacting WordPress and its associated plugins.

One common and highly effective tool to scan for these vulnerabilities is wpscan.

While WPScan is written in Ruby, it remains a powerful tool for discovering known vulnerabilities. During the fingerprinting phase of an assessment, one should have discovered the technologies running on the target’s assets, making it straightforward to identify sites running WordPress. Once a site is found, a scan can be executed using the following command structure:

The vast majority of sites scanned will be patched because most of these WordPress sites are managed by third-party vendors who perform automatic updates. However, vulnerable plugins are encountered quite frequently, though it is important to note that many of these exploits may require credentials to be leveraged successfully.

Another common finding is the direct listing on the uploads folder. This is a configuration flaw that can expose sensitive files. Analysts should always make sure to check the following path:

In these directories, one can often find sensitive information such as user emails, passwords, paid digital products, and much more, offering a significant compromise opportunity.

Drupal: A Key Enterprise CMS

Drupal is the third most popular CMS globally, and it is frequently encountered, perhaps even more often than Joomla in certain enterprise environments. If a Drupal site is discovered, the preferred tool for scanning its security posture is droopescan. This scanner is versatile and also has the ability to scan additional CMSs.

Joomla: The Second Major Player

While WordPress is by far the most popular CMS, Joomla comes in second, meaning analysts can expect to encounter this CMS as well. In contrast to WordPress sites, which often appear to be fairly locked down (due to extensive patch management), Joomla sites have historically presented more frequent configuration and security issues. The most popular tool for scanning Joomla vulnerabilities is Joomscan.

Adobe AEM: A High-Value Target

If one ever runs into the Adobe Experience Manager (AEM) CMS, it is often an immediate indicator of a high likelihood of finding vulnerabilities. For many in the security community, AEM is regarded as a system that is often riddled with public vulnerabilities.

The tool of choice for scanning an AEM application for vulnerabilities is aemhacker.

Note on SSRF Testing: In order to test for Server-Side Request Forgery (SSRF) vulnerabilities within AEM, a public IP address is required. This is necessary so that the target server can successfully connect back to the testing machine, confirming the presence of the vulnerability.

Other CMS Frameworks: The Hunting Process

There are hundreds of different CMSs, making it impractical to maintain a list of specific tools for every one. While the vast majority of sites will be running WordPress, Joomla, and Drupal, other CMSs will inevitably be encountered.

If a less common CMS is discovered, the first step is to consult Exploit-DB to see if any known Common Vulnerabilities and Exposures (CVEs) exist for the platform.

For instance, if a CMS named “Magento” is discovered, the researcher would perform a search on Exploit-DB for known issues.

In addition to finding single exploits, it is highly recommended to search GitHub to determine if there is a specialized tool that can scan for all possible vulnerabilities and misconfigurations. Just like the tools for WordPress, Drupal, Joomla, and Adobe AEM, there are dedicated scanners that target other platforms.

As an example, searching may reveal that a Magento vulnerability scanner called magescan exists and can be utilized.

It is crucial to use this structured process whenever a CMS framework is encountered that is not immediately recognized.

Conclusion: CMS Vulnerability Scanning

Over half of the internet is being run by a CMS framework. Therefore, one is almost guaranteed to run into a CMS at some point or another during an assessment. When a CMS is found, the goal is to avoid wasting time manually testing the endpoint. Instead, the priority is to quickly and efficiently test for known CVEs and common misconfigurations. The best way to achieve this is to find some sort of CMS-specific vulnerability scanner. If a scanner cannot be located, the next steps are to search Exploit-DB and Google for known CVEs. If all these efforts come up empty-handed, it is often best to move on to other targets, unless the analyst is specifically hunting for zero-day vulnerabilities.

II. Basic Hacking: GitHub for Sensitive Information Disclosure

Introduction to GitHub Reconnaissance

GitHub is a web-based version-control and collaboration platform primarily used by software developers. As of right now, pillaging GitHub for sensitive information disclosures is one of the easiest ways to compromise an organization and is a common technique for finding easy, high-impact findings.

Finding Sensitive Information

It is important to remember that it does not matter how hardened an organization’s external perimeter is if their developers are hard-coding credentials and posting them online. This is a direct path to compromise.

It is a common practice for developers to hard-code test accounts, API keys, or other credentials when writing and testing a piece of software. This simplifies development, as they do not have to enter credentials every time they run or test the program. However, more often than not, these credentials remain in the source code when the code is pushed to a public GitHub repository, making them viewable by anyone.

The first essential component for this technique is a list of sensitive keywords to search on. This can include file names, file extensions, variable names, or any other term that might indicate sensitive data.

A good starting list of sensitive keywords is maintained and shared by the user “@obheda12” (the link to this resource should be integrated here, if it was provided in the original content).

Once a list of sensitive terms is prepared, the hunt can begin! A typical search involves typing the target’s domain followed by the GitHub Dork (a specific search query), as illustrated below:

When searching for the domain “hackerone.com” and the term “password,” for example, it may yield thousands of results. In a typical scenario, a researcher would likely spend a few hours manually sorting through a large portion of these results before finding a “juicy” (high-value) piece of information. Having to spend hours sorting through a volume of low-value results is often the only downside to this technique. However, when something valuable is found, it typically leads to an instant high or critical security finding.

Conclusion: GitHub Hacking

As of right now, GitHub represents one of the easiest avenues for obtaining a high or critical vulnerability. Almost every developer uses GitHub, and these developers often hard-code passwords and keys into their source code. As long as one is willing to spend a few hours diligently searching through potentially thousands of repositories, a valuable security finding is almost guaranteed.

III. Basic Hacking: Subdomain Takeover

Introduction to Subdomain Takeover

Another widely recognized vulnerability is subdomain takeover. While the frequency of this vulnerability has decreased somewhat in recent years, it is still very common in the wild.

According to Google, “Subdomain takeover attacks are a class of security issues where an attacker is able to seize control of an organization’s subdomain via cloud services like AWS or Azure.”

Understanding Subdomain Takeover Mechanics

A subdomain takeover occurs when a subdomain (e.g., test.example.com) is pointing to another domain via a CNAME record (Canonical Name) that no longer exists or has been deactivated. If an attacker is able to register the non-existing domain that the CNAME record is pointing to, the target’s subdomain will now point to the attacker’s newly registered domain, effectively granting the attacker full control over the target’s subdomain.

The key vulnerability is that the target subdomain’s DNS record points to a domain that is currently unregistered. An attacker can then register this dangling domain. Once registered, the target subdomain resolves to an asset the attacker controls. This vulnerability is particularly interesting because an asset can be secure one minute, and a single, un-cleaned-up DNS change can make it vulnerable the next.

For those planning to hunt for this vulnerability, the following GitHub page is an invaluable resource, as it contains a large number of examples and walkthroughs on exploiting different service providers:

This page contains an extensive list of cloud providers and services that can be exploited by this vulnerability. Clicking on the specific issue number typically provides a detailed walk-through for exploiting that particular service or “engine.” Because every provider has its own unique process for registering and configuring domains, it is necessary to learn the specific registration process for the engine that impacts the target.

GitHub Takeover Walkthrough

One of the easiest ways to spot a subdomain takeover vulnerability is by the characteristic error message it returns.

For instance, when visiting a vulnerable target site, it may return a 404 status code and display the error message: “There isn’t a GitHub Pages site here.” Consulting the subdomain takeover wiki confirms that this specific error message is a strong indicator of a potential subdomain takeover vulnerability.

Now that there is an indicator that the site may be vulnerable, the next step is to identify the specific GitHub page that the vulnerable subdomain is pointing to. This information is needed so the attacker can register the domain through the GitHub platform.

A dig command can be used to gather the DNS records of the vulnerable domain. The output will reveal that the domain points to a GitHub page, such as ghostlulzvulntakeover.github.io. If this specific domain can be registered, the takeover is successful. To determine the exact process for registering a domain on GitHub, one can perform a Google search or follow the tutorial provided in the subdomain takeover GitHub page.

Once the steps for registering a domain on GitHub are known, the execution phase begins.

  1. A GitHub repository is created with the exact same name as the CNAME record (e.g., ghostlulzvulntakeover).
  2. An index.html file is then created within the repository, which will serve as the content that appears on the target’s subdomain.
  3. The next step involves setting the repository as the main branch (or equivalent primary setting).
  4. Finally, the target domain that is being taken over is specified in the repository’s settings.

That is it! Upon visiting the target domain, the page set up in the new repository should now appear. The subdomain takeover is successfully exploited, and the custom page appears on the target’s subdomain.

It is important to remember that this process is specific to GitHub. If the target is vulnerable to another provider (like an AWS S3 bucket or an Azure service), the corresponding steps for that provider must be followed. Fortunately, all these scenarios are well-documented on the subdomain takeover GitHub wiki.

Conclusion: Subdomain Takeover

Although subdomain takeover has recently started to die down in prevalence, plenty of organizations remain vulnerable to this type of attack. It is extremely easy to execute and allows the attacker to completely take over the target subdomain, often leading to a simple, high-impact security finding.

Exit mobile version