Category: Vulnerability

Rated the best search engine for hackers, Shodan was referred to as the scariest search engine on the internet, back in 2013. While Shodan is similar to Google, in that they are both search engines that use crawlers, it crawls the entire internet to map and index internet-connected IoT devices. To put this into perspective, Google’s crawlers only index a part of the internet that is publicly accessible, the World Wide Web. And although Shodan is infamous for being instrumental in blackhat hacking, in the right hands, this search engine is effective in the process of vulnerability assessment and pentesting IoT devices. 

In this article we delve into Shodan and its working, and discuss the features that make this search engine useful for pentesters and bug bounty hunters.

What is Shodan?

As mentioned earlier, Shodan (Sentient Hyper-Optimized Data Access Network) is a search engine for devices connected to the internet. Designed and developed by Web Developer John Matherly, this search engine crawls the entire internet, parses the service banners of IoT devices, and indexes them for future searches. It maps and reports any device, such as webcams, smart devices, medical devices, traffic lights, C2 systems of devices, etc., that is connected to the internet and is not secure. 

The service banners of IoT devices contain metadata relevant to the devices, such as:

• Geo-location
• Make and model
• IP address
• Default username and password
• Software version

How does Shodan work?

Upon scanning the entire internet, the search engine sends queries to connected IoT devices for publicly available information related to them. The servers of such devices return their service banners to the user. Shodan also supports customized queries using filters like city, country, hostname, OS, etc. to find out the corresponding details.

The Basics

Similar to other search engines, Shodan also utilizes a search box, to which users can enter search terms that adhere to its search query syntax. Moreover, search results can be narrowed down to be as accurate as possible, by making use of quotation marks and other such operators. 

For instance, boolean operators + or — can be used to include or exclude terms in the query.

Shodan Filters

This search engine only searches for the data property on the IoT devices’ banners. Hence, it employs search filters for refined results. Here are some basic search filters you can use:

• city: find devices in a particular city
• country: find devices in a particular country
• geo: you can pass it coordinates
• hostname: find values that match the hostname
• net: search based on an IP or /x CIDR
• os: search based on operating system
• port: find particular ports that are open
• before/after: find results within a timeframe

Search examples:

org:”Amazon” ssl:”target”

ssl:”target”

html:”Dashboard Jenkins”

http.component:”jenkins”

http.title:”302 Found”

http.component:”java”

ssl.cert.subject.cn:”target”

hostname:”target”

http.favicon.hash:-335242539

html:”© 2020 target”

product:elastic port:9200

Continuous Monitoring

This IoT search engine can be used to monitor your networks or products continuously, to help you stay informed of any threats to them. For this, you can make use of the Shodan Command-line Interface (CLI).

• Use the following command to set up an alert for notifications related to your IP range:

shodan alert create “Bug-Bounty-Target” 198.172.0.0/24

• The following command allows you to create a trigger to send the alert:

shodan alert triggers

• When Shodan detects a malware or a new CVE against your product, get a notification using this:

shodan alert enable {ALERTID} malware

Automation

Every new trick boils down to automation these days. Fortunately, with this search engine you can automate various tasks that are within its range of activities. There are the three main ways to automate this search engine:

• Shodan-API
• Shodan Python Module
• Shodan CLI

Check out this handy tool that makes the entire process easier and hassle-free: m4ll0k/Shodanfy.py

Conclusion

Although it seems quite perverse, security professionals, researchers, and even government agencies trust Shodan to alert them on unmanaged IoT devices that may present vulnerabilities. Such devices could potentially expose critical data belonging to an enterprise, organization or individual, to attacks. This search engine helps prevent this. By following the methods prescribed above, you can also explore Shodan and monitor and protect your network or product from exploitation. 

Read Part 1 on GraphQL here.

In last week’s blog we learnt about the basics of GraphQL and how to configure a GraphQL server. We also discussed some key differences between GraphQL and REST API. 

Here’s a brief recap:

GraphQL is an open source query language for APIs that helps to load data from a server to the client in a much simpler way. Comparing multiple aspects of both GraphQL and REST API, we have seen that GraphQL operations are superior to that of REST API. Although the benefits of this open source language is plenty, it comes with security vulnerabilities that developers tend to encounter from time to time. 

Picking up from there, in the second part, we will discuss:

• GraphQL: Common misconfigurations that enable hackers
• Testing common misconfigurations in GraphQL

GraphQL: Common misconfigurations that enable hackers

GraphQL is one of the most efficient and flexible alternatives to REST API. However, it is vulnerable to the same attacks that REST API is prone to. 

GraphQL depends on API developers to implement its schema for data validation. During this process they could inadvertently introduce errors. In addition to this, new features and functionalities, which meet client requirements, are added to web applications by the hour. This also increases the chance of developers committing errors.

Here we highlight some of the common misconfigurations and issues with GraphQL, that allow hackers to exploit it.

• Improper Access Control or Authorization Checks

The limitations of the user authentication process can potentially grant unauthorized access to anyone. In the event that the authentication process is defective, the web application fails to restrict access to an object or resource which leads to delivering the data of another user without performing authorization checks. The flawed method allows attackers to bypass the intended access restriction, exposing user data to abuse, deletion, or alteration.

Let’s consider the scenario where a user, with the numeric object ID: 5002, wants to retrieve his/her PII such as email ID, password, name, mobile number, etc. If this user knowingly or unknowingly uses a different user ID (say, 5005), and this ID belongs to another active user, but the search leaks his/ her data, it shows that the GraphQL resolver allows unauthorized access. 

The following query consists of a user ID representing a logged in user and fetches the user’s PII:

query userData {

  users(id: 5002) {

    name

    email

    id

    password

    mobileNumber

    authorizationKey

    bankAccountNumber

    cvvNumber

  }

}

However, if the same authenticated user is able to fetch the data of ID 5005, that means there is improper access control to an object or resource. It enables hackers/ attackers to access the data of multiple users. It also allows an attacker to perform malicious activities like editing the user’s data, deleting the user from the database, etc.

• Rate Limit Issue and Nested GraphQL queries leading DoS attack

In a single query, it is capable of taking multiple actions in response to multiple HTTP requests. This feature increases the complexity of GraphQL APIs, which makes it difficult for API developers to limit the number of HTTP requests. If the request is not properly handled by the resolver at the GraphQL API layer then it opens a door for actors to attack the API and to perform denial-of-service (DoS) attacks.

To avoid this, only a specific number of requests per minute should be allowed to the API, and in case the number of requests exceeds the limit, it should trigger an error or reject the response.

Let’s look at the following example of such nested queries:

query nestedQuery {

  allUsers {

    posts {

      follower {

        author {

          posts {

            follower {

              author {

                posts {

                  follower {

                    author {

                      posts {

                        id

                      }

                    }

                  }

                }

              }

            }

          }

        }

      }

    }

  }

}

• Default introspection system reveals internal information

Some API endpoints enable server-to-server communications and are not meant for the general public. And yet, GraphQL’s feature of introspection makes this possible without much difficulty. 

Assume the instance where someone sends a query against an internal endpoint only to gain access to admin credentials and thereby obtain Admin Privilege. 

Here is an example of a single endpoint which has the potential to allow attackers to access hidden API calls from the backend. 

There are several websites such as https://apis.guru/graphql-voyager/ that display the entire list of API calls available at the backend. This provides a better understanding of the its interface and also demonstrates ways to gather sensitive information from the server. 

We have covered a few of the misconfigurations here, but there could be many others. Also, it is vulnerable to all bugs that affect any other API.

Testing common misconfigurations in GraphQL

Here we’ll be exploring two ways to test these common misconfigurations, further exploited to gain access to sensitive data or information:

• Burp Suite – Advance intercepting proxy tool
• Altair GraphQL – GraphQL interface available as software, extension for OS and browser.

Testing GraphQL misconfigurations with Burp Suite

Burp Suite is a popular pentesting framework that works as a great proxy tool to intercept and visualize requests. Assuming that readers are already aware of how to configure it, we’ll be focusing on testing alone. 

• This is what a normal HTTP request in GraphQL looks like:
• Modify the POST query per your requirements and send it to the server. 
• If it is misconfigured, it will fetch sensitive/ internal data. 
• However, if you find it difficult to visualize or modify the query, you can use a Burp plugin called “GraphQL” to achieve the same results.

But the major drawback of testing it in Burp Suite is the inadequate visualization of the entire schema documentation. This could result in several common misconfigurations being overlooked, unless we locate the proper documentation of API endpoints or calls implemented at the backend. Another issue related to using Burp is that we have to modify or debug the query manually which makes the process more complex. All these issues can be resolved with the help of the following method.

Debugging GraphQL with Altair GraphQL 

Altair helps with debugging GraphQL queries and server implementations. It rectifies the problem of modifying the queries manually and instead helps to focus on other aspects. 

Altair GraphQL is available as a software for Mac, Linux, and Windows OS and also as an extension for almost all browsers. It provides proper documentation of the entire schema that is available at the backend. All we need to do is configure the web application we are testing.

All three operations of GraphQL can be seen in the documentation section as shown above. You can further explore these options to get other fields, API endpoints, etc.

Altair is capable of solving one of the most challenging tasks in this process: Adding a query manually. It comes with the feature that enables automatic query generation. So, all we need to do is pass supported type values.

• Click on the ADD QUERY as shown above, to automatically add a query along with its arguments and fields. 
• Now, provide the argument values to test for any bugs or misconfigurations.

Altair makes bug hunting on any web application quite easy. You can test GraphQL queries and server implementations easily, as Altair performs the complex part of the process and lets you focus on the results.

Conclusion

In comparison with REST API, GraphQL offers developers improved standards of API development. And yet, it has its own security misconfigurations that can be exploited relatively easily. However, it is capable of bridging the gaps created by REST API. Alternatively, REST can help address the drawbacks of GraphQL as well. They need not be referred to as two incompatible technologies. Moreover, we believe these technologies can coexist with each other.