Streamlining DNS Security: Automating our Defences

DNS security plays a crucial role in an organization’s overall security management. In this blog, we will discuss how we achieve comprehensive asset inventory and automate various security checks to always stay ahead of threat vectors.

60 seconds takeaway

1. Having a comprehensive Domain Name System (DNS) asset inventory is crucial for maintaining an organization’s overall security.
2. Asset inventory enables the security team to determine the size of the attack surface and understand the organization’s vulnerabilities.
3. Although third-party vendors can monitor domains in a black box manner, and open-source tools like Shodan, Censys, and certificate logs can help identify publicly available assets, none of them can guarantee the complete discovery of all assets. Without full knowledge of public assets, an organization might be vulnerable to critical security issues.
4. In this blog, we will explore how to make an asset inventory that covers 100% of an organization’s assets, the importance of DNS-related security issues that generally occur in organizations, and how we are solving them at Meesho.

What is DNS?

In today’s technology-driven world, accessing a website has become second nature to us. We simply enter a website’s domain name into our preferred web browser, and within seconds, the site appears on our screen. However, several complex processes take place in the background. When we type a website’s domain name in our browser and press enter, the request is initially handled by a Domain Name Server (DNS). This server converts the domain name to an IP address, which is the location where the website is hosted.

In this blog, we will not delve into the details of how DNS is resolved to an IP address. Instead, we will directly discuss DNS records, which are managed by the domain owner, and security issues.

What are DNS Records?

DNS Records are the specific pieces of information stored in the Authoritative DNS, which is used to map a domain name to its corresponding IP address or map the mail server associated with the domain.

To access the website or services, the domain owner is responsible for updating the DNS records correctly in the Authoritative DNS. As the process requires human intervention, this sometimes leads to various security issues, which we will discuss here.

Problem statement

The absence of an on-demand DNS inventory can lead to significant security concerns, particularly with regard to unauthorized DNS alterations. These alterations could result in several potential risks, including public NX-Domain entries, dangling DNS entries, NS record takeover, and CNAME record takeover. In the past, we worked with third-party vendors to alert us to such security issues, but no third-party or open-source tool can guarantee a fully comprehensive asset inventory with 100% accuracy.

In addition, the absence of an on-demand DNS inventory can make it difficult to enforce DNS security policies, including those related to domain name ownership, DNS zone transfers, and record updates. As a result, unauthorized changes to DNS configurations may occur, leaving the network exposed to potential attacks.

In the past, we had to manually initiate our internal Dynamic Application Security Testing (DAST) automation framework every time a new asset was created. As a result, we needed an automated solution that could periodically scan for new entries and trigger the DAST automation.

Finally, a lack of DNS inventory can make it harder to identify and investigate security incidents involving DNS data. This can hamper forensic analysis and hinder efforts to identify the root cause of a security breach.

Solutions

We developed an in-house automation solution using Python to tackle the challenges mentioned above. Our script leverages the Boto3 library to extract records from our authoritative DNS server. This script is designed to efficiently and accurately perform the tasks of maintaining an asset inventory, identifying subdomain takeover vulnerabilities, detecting NX-domain entries, and checking for dangling DNS entries. The script is set to run daily and provides notifications for any potential issues that are detected.

Our automation process is divided into two parts. The first part involves extracting records from AWS Route53 to prepare a comprehensive asset inventory and notify us of any new subdomain entries. The second part is dedicated to identifying DNS-related vulnerabilities.

Fetching records from AWS Route53

We utilize the boto3 library in Python to fetch domain and subdomain information from Amazon’s Route53 service. To achieve this, we employ a two-step process. Firstly, we retrieve a list of all hosted zones in our account using the list_hosted_zones() method. Then, we iterate through each hosted zone and use the get_hosted_zone() method to fetch the subdomain information for that particular domain.

Afterward, we conduct a comparison between the results obtained from the database. If there are any newly discovered entries, they will be updated in the database, and subsequently sent to the DAST pipeline for further processing.

Checking DNS vulnerabilities

Understanding Authoritative NS Records and NS Record Takeover

When a domain is registered, its authoritative NS (Name Server) records are configured at the TLD (Top-Level Domain) level, such as .com. These NS records point to the DNS servers that are responsible for resolving any queries for that domain.

For example, if the domain “example.com” has been registered and its NS records are set up in the .com TLD, any queries for *.example.com will be directed to the DNS servers specified in those NS records. These DNS servers will then provide the IP address or other information associated with that domain.

Most of the time, organizations set up multiple authoritative NS records for their domains to increase DNS reliability and availability. This provides redundancy in case one server fails, distributes the load among multiple servers, and improves performance, but sometimes this leads to security issues when changes are not tracked or documented by the DevOps teams. If changes are made to NS records without updating the TLD, it can cause the domain’s DNS requests to be redirected to unauthorized servers or sometimes lead to a DNS takeover.

We have developed a straightforward approach to identifying NS records that do not belong to our organization. The process involves retrieving all NS records from our Route53 and subsequently retrieving the authoritative DNS records from the TLD, one by one. Any discrepancies between the records will trigger a notification to be sent to us via Slack, alerting us of a potential issue.

This is the most updated community support project which is tracking the services which are vulnerable to DNS takeover.
https://github.com/indianajson/can-i-take-over-dns

Subdomain CNAME and third-party services takeover

CNAME records, also known as canonical name records, are generally used to map third-party subdomains to an organization’s domains. At some point in time, an organization stops using these third-party services but forgets to remove the CNAME records that were created on the authoritative DNS servers. Due to this, sometimes attackers can takeover subdomains by creating the same CNAME records due to poor verification on these third-party services, which leads to subdomain takeover because the DNS resolution process prioritizes the CNAME record over other records.

To detect potential subdomain takeover vulnerabilities involving third-party services, we are using the signature-based detection technique. This technique involves searching for specific keywords in the response that matches a predefined signature. If a match is found, the subdomain is flagged as potentially vulnerable. By using this technique, potential CNAME takeover vulnerabilities can be identified and addressed before they can be exploited.

This is the most updated community support project which is tracking the services which are vulnerable to CNAME takeover.
https://github.com/EdOverflow/can-i-take-over-xyz

Dangling Records and NX-Domain DNS Entries:

When a DNS server fails to resolve a domain to an IP address, it returns an NXDOMAIN response, which indicates that the domain does not exist. This issue is also known as a non-existent domain and can occur when the service that was previously associated with the domain no longer exists. If an organization is using a cloud service such as AWS or Gcloud, it is essential to remove any NX-Domain entries in a timely manner. This is because the IP addresses used by these cloud services are often allocated from a shared range, and the IP addresses might get assigned to a different organization and DNS entries start pointing to a resource that an organization doesn’t own.

To address the NXDOMAIN issue, we fetch all the DNS records from our route53 and query each record. If any of the queries return an NXDOMAIN response, an alert is sent via Slack. This approach helps ensure that any potential DNS issues are quickly identified and addressed before they can impact the organization’s services.

Putting all together

If we put everything together and combine the whole automation process the architecture will look like this. Which covers fetching the records from AWS and Checking for DNS-related security issues.

Impact of DNS Automation

Previously, the security team was heavily dependent on the DevOps team to manually fetch the assets from the route53, which led to a high turnaround time. However, with the automation of the process, the security team can now easily access the assets and take necessary actions to detect any vulnerabilities. As a result, the dependency on the DevOps team has been considerably reduced, allowing the security team to work more independently and proactively.

With the implementation of our DNS security scanner, we can now efficiently detect new subdomains, as well as DNS-related security misconfigurations. This has significantly reduced the time required to identify and patch such issues, compared to the previous approach where we relied on a third-party scanner to detect security issues.

Earlier, we had to feed our assets to our internal DAST automation manually but now, with the help of DNS automation, the list of all the assets is updated automatically and DAST scan will trigger automatically whenever new assets are identified.

Success metrics

• Faster detection: The implementation of automation in DevOps has significantly reduced the time taken to retrieve critical information. In the past, it would take approximately 1 day to obtain a comprehensive list from DevOps, but with automation, the process now takes only 5 minutes. Apart from its time-saving benefits, automation has also proved to be a game-changer in detecting DNS security issues. With the help of automated scans, the system can scan massive amounts of DNS data and detect potential vulnerabilities within minutes.
• Consistent results: Automating DNS security issue discovery can help ensure that the same tests are run consistently each time, reducing the risk of human error and making it easier to compare results over time.
• Scalability: This automation can scale to handle large volumes of DNS traffic, which is critical for Meesho which has complex networks and multiple domains.
• Increased Efficiency: This automation can save time and resources by allowing security teams to focus on high-priority tasks and reducing the amount of manual effort required to detect and remediate DNS security issues.
• Improved accuracy: This automation is less likely to miss DNS security issues than manual methods, as this can perform more comprehensive tests and detect issues that might be overlooked by human analysts.
• Better visibility: This tool can provide greater visibility which can be later leveraged to look into DNS traffic and activity, making it easier to identify trends, patterns, and potential threats.
• Proactive security: Automating DNS security issue discovery can help Meesho take a more proactive approach to security by identifying potential vulnerabilities before they can be exploited by attackers.

That’s all folks!

PS shoutout to Usman Zafar for helping me write the blog and Rahul Prakash for helping me with this cover image.

Do these problems excite you? Do you want to be a part of the team that is pushing frontiers and probing into untouched territories? Go to our jobs section and apply for a position that fits you the best!

Can’t find something suitable at this point? Keep an eye out on this space and be the first one to apply when the position opens.