Some security professionals across the world would say that one does not need to learn coding to hunt for bugs in web applications. In fact, some experienced security professionals would go even further to suggest that entry-level positions in cybersecurity and hacking does not require extensive knowledge of programming.
Although this holds true to some extent, a career in hacking and pen-testing web applications demands in-depth knowledge in programming.
Where do many researchers go wrong?
In case of Cross-Site Scripting (XSS) attacks, for instance, researchers report the bugs by triggering an alert. This clearly does not call for advanced understanding of programming.
But they may lack the skills to exploit the same bug to create a javascript code so as to steal cookies or leverage the XSS bug to carry out other malicious activities.
Inspired by such bounty hunters, beginners in the field assume that all they have to do is fire up Burp Intruder, add a list of payloads, and prompt an alert on the browser to earn a quick buck.
Why do you need to learn programming in security testing?
Understanding the application:
Awareness and proficiency in programming can help a researcher understand an application’s infrastructure and the implementation of its many functionalities. Once you are familiar with the workings and technicalities of web applications, even entry-level programmers can certainly outsmart amateur coding enthusiasts.
Attack automation:
Hackers use tools such as Nmap, Metasploit, Amass, etc. to automate enumeration and exploitation processes. Automation of enumeration attacks saves them a lot of time and effort. By learning how to code, you are also opening yourself up to vast knowledge, which can guide a beginner to build such tools on their own. Apart from that, while pen-testing, a programmer at some point will have to write a code that can exploit a vulnerability; for instance, when you have to pass the current timestamp along with a request, you need to automate it using coding. This requires that you are well versed with programming.
Conclusion
Programming is said to be the future of innovations, and a necessary skill to master. Therefore, a security professional should undergo training and have adequate knowledge regarding programming. Anyone pursuing a career in penetration testing should consider programming as an essential part of their occupation. It does not merely set you apart from peers, but also gives you a competitive advantage over them.
Web applications form a major part of an organization’s attack surface and according to Verizon’s 2020 Data Breach Investigation Report, web applications are the single most significant cause for data breaches. Web application attacks account for 43% of all successful data breaches.
These websites contain several vulnerabilities such as Remote Code Execution (RCE), Server-Side Request Forgery (SSRF), Local File Inclusion (LFI), Server Side Template Injection (SSTI), and more. Some of these vulnerabilities allow intrusion of corporate networks. These vulnerabilities are the result of mistakes that programmers make. Developers trust and hope that their applications will end up in the right hands, which often turns out to be the biggest mistake they ever made.
In this multi-part series about web apps, we explore the common mistakes and threats affecting web applications, as well as point out factors regarding applications that appeal to threat actors. The first part of this multi-part series focuses on web app user input and the pitfalls of not validating or sanitizing it. The article also sheds a light on the steps one can take to prevent application attacks and reduce vulnerabilities.
Rule #1: Never trust user input
While developing an application, web programmers should refrain from accepting data from users and in fact should presume all data is bad until proven otherwise. This is how threat actors leverage different vulnerabilities:
Remote Code Execution
In an instance where the Image File Upload functionality of an application uploads the filename and contents onto a server, the server processes it further. However, if the application doesn’t validate user inputs, it permits the attacker to upload the server side language extension file, such as the .php file. This further allows the attacker to execute OS commands on the server.
Local File Inclusion
Similarly, when web applications are coded poorly, hackers can inject local files into the include statements. For instance, an attacker can exploit the Local File Inclusion vulnerability by changing the path of a PDF file with that of another sensitive file such as passwd. If the application doesn’t validate the input, the attacker can simply read internal server files.
In an attack that exploits this vulnerability hackers gain partial or complete access to the requests sent by the application, to abuse a functionality. This allows them to make the server-side application to configure HTTP requests that lead to malicious domains of the attacker’s choice. If the website does not validate the user input, the hacker can access internal server files and more.
This vulnerability allows hackers to insert or inject a query into an entry field, so as to execute malicious SQL statements. This enables actors to retrieve sensitive data from the database evading any security measures.
From the above instances and scenarios it is clear that if the user input is not properly validated or sanitized, most web app vulnerabilities can be exploited, eventually leading to breaches and data loss.
How can you reduce vulnerabilities and prevent attacks
Let us look at the issue at hand before we suggest a solution. The following instance summarizes the problem:
This is a test application that accepts the user input and returns results based on it.
An average user looks up topics such as Python or JAVA, while hackers with a malicious intent would submit something like this:
There are a number of symbols we can inject, such as a single quote(‘), double quotes (“), open, closed angle brackets (<>), equals to (=), and open, closed brackets [()], and if the web application accepts these without validating them, attackers can used this as a weapon to steal session cookies of other people, by using advanced XSS payloads (Cross-Site scripting payloads).
Now, let’s try to understand the logic of the code:
The GET variable named $_GET[‘vulnparam’]at the TOP accepts the user input, which then allows the webapp to proceed with that variable name $vulparam. As you may have noticed, the user input variable $_GET[‘vulnparam’] is not validated. The web application is using it as it is.
In order to validate the user input first, we use the htmlentities() function that converts characters and symbols to HTML entities. This helps to prevent Cross-site Scripting (XSS) attacks and the web app proceeds further with the encoded user input.
Summary
Almost every OWASP Web Vulnerability is exploited in real world websites as web applications fail to properly validate user input, before processing it. Therefore, it is important that app developers and security testers regularly collaborate with each other. Once the programmer has built a particular feature or an app, security testers can test it before deploying them on the prod servers. Ultimately, this will save them a lot of time and prevent any data loss that could have resulted from exploitation.
Cloud-based encrypted communication platform – Telegram – became an overnight sensation, owing to a WhatsApp outage that occurred in 2018. The user base of Telegram hit a whopping 400 million, as of April 2020, since its inception in the year 2013. The non-intrusive nature of the app, contrary to the likes of Facebook Messenger and WhatsApp, is another reason for its popularity.
However, over the years, the app and its developer Pavel Durov have also been on the receiving end of some criticism. The anonymous secure connection of Telegram allows users to access selectively prohibited networks and websites. Among other proxy servers and VPN services, Telegram is also completely or partially banned across several countries that are unwilling to risk national security. Furthermore, the app is not as secure as it claims to be. Its security flaws have been a major cause for data leaks.
InRussia, a struggle that ensued between the Federal Security Service (FSB) and Telegram, after the St. Petersburg bombing, resulted in the application’s ban in 2018. Pavel Durov refused to share the encrypted messages of the suicide bomber who was apparently active on the messaging platform. A court maintained that the app remain banned until its developer agreed to hand over its data encryption keys to the authorities. Russian authorities failed to hold up the ban successfully and decided to lift the ban only recently.
In 2016, 15 millionIranian users’ records were leaked following a major data breach. Iranian hackers exploited the security flaws in Telegram to compromise accounts. In particular, they hacked the SMS verification codes that are generally sent to the users. This attack targeted Saudi royals, NATO officials, and even nuclear scientists.
In a more recent event, pro-democracy campaigners inHong Kong coordinated their demonstrations against their government using Telegram. Although the app has been banned in the country since 2015, users found a way around it.
InGermany, the police launched a crackdown on criminals to prevent premeditated crimes. For this they only had to use proprietary software to hack into Telegram correspondences. The police successfully carried this out for two years.
Why should you monitor Telegram for threats?
The anonymity associated with the app is concern for regulators and governments. It increases the odds of misuse of the app’s features. Which is why Telegram activities on the app should be monitored for the following reasons:
Selective chat encryption
Although users tend to think that their correspondences are all encrypted and secure, the app requires you to change the settings to “activate” end-to-end encrypted chats. Most users are not aware of this.
Proprietary encryption
Telegram relies on the symmetric encryption method and uses proprietary protocol MTproto, making it difficult external cryptographers to audit its efficacy.
Exposes Metadata
Researchers have uncovered flaws in the app whereby an attacker can snoop on significant data about the user, apart from their chats. For instance, the attacker can figure out when the user is online and offline. This could in turn help them determine who the user is talking to, which is a rather serious flaw.
Breeding ground for illegal activities
In a 2016 report by Memri, Telegram wasreferred to as “the app of choice for many ISIS, pro-ISIS and other jihadi and terrorist elements.” Terrorist organizations weaponize Telegram to disseminate hatred and misinformation. The anonymity that the messaging app offers indirectly, endorses criminal activities, harmful to civilians and governments alike.
Corrupted files
Latest research from Symantec indicates that media files shared on WhatsApp and Telegram can be manipulated using a malware. This security flaw, known as media file jacking, exists in Android devices. It allows attackers to intercept the process by which applications save media files on the device’s storage.
Command and control
The ‘Masad Clipper and Stealer’ malware, capable of allowing hackers to access user’s personal information and their crypto wallets, was sold via Telegram channels. The Telegram channel was also a makeshift command and control for the same malware.
CloudSEK’s proprietary cyber threat monitoring platformXVigil gathers information from Internet Relay Chat (IRC) and chat rooms (for instance, Telegram Channels). The platform then detects conversations that are intended to obtain information about your organisation, and weaponize it against you. XVigil crawls across various parts of the internet to find mentions of your digital assets, so that you can take proactive measures to prevent any external threats to your brand and infrastructure.
An Android app is a software that runs on devices powered by the Android operating system. Android apps are commonly written in Java programming language and compiled to bytecode. These applications are basically Android Package Kits (APK files) that enable the distribution and installation of Android applications. This is similar to how .exe files are used in Windows OS. The second quarter of 2020 registered 2.96 million Android apps in total compared to 2.6 million in 2018 (on Google Play). And in 2018, high risk vulnerabilities were found in 43% Android applications.
An APK file contains the following components:
AndroidManifest.xml: which inturn contains details such as the name of the package, description of access rights, as well as that of the API components.
res /:A folder that contains app resources, which does not include precompiled application resources.
classes.dex: Application code compiled in dex format that are executable by Dalvik virtual machine.
META-INF/: A folder that contains the hashes and signatures of all files.
Application sandboxing
Unlike Windows, Android runs each of its applications in a sandbox environment. Application sandboxing or containerization limits the environment in which a code can be executed. It intends to protect the app from interacting with external malicious elements.
The Android operating system is based on the Linux system which uses the Linux kernel. But unlike the Linux system, each Android application is assigned a unique user ID. The system then sets permissions for a particular user ID, permitting that app alone to access certain features.
Typically, all Android apps have to request permission to access sensitive data such as contacts, SMSs, and cameras . All these system features are restricted with the help of the Permissions API. The application is permitted to access system features only if the user grants access.
Applications and processes
Although Android applications are written in Java, the class files that contain Java virtual machine instructions (Java bytecode) are converted to Dalvik executable files (.dex files) that contain Dalvik bytecodes, before they are installed.
The kernel that is used by Android OS manages the working of each application on the device, where Dalvik virtual machine runs independent processes or applications under different user IDs.
Sandbox escape
Web applications have universal links to interact with other applications, unlike Android apps.
Android app-to-app communications are limited, however, it is achieved through the following methods:
Intents/ Deeplinks
An intent is used to request action from a different application component. It helps to coordinate the activities carried out by different applications. For example, selecting a photo from your gallery to set your WhatsApp display picture.
Deeplinks are links that direct you to a specific destination from an application.
Deeplinks is what makes it possible for users to share the link to a Medium article on Twitter.
Binder IPC
A Binder enables inter-process communication (IPC) within a kernel. It allows processes to manage shared data. Object Linking and Embedding (OLE) by Microsoft is an example of an IPC.
Content Providers
Content providers manage the access to the central repository of data. They provide data to external applications. For instance, content providers grant access to applications to use the contacts and SMSs on a device.
Even though Android applications are typically sandboxed and isolated, limiting app-to-app communications, they can still be abused.
What goes wrong?
App misconfiguration or the developer’s bad coding practices make Android applications vulnerable to cyber attacks. Listed below are the most common Android application security issues that developers and users come across.
Hardcoded credentials
Hardcoded credentials are basically plain text passwords, API keys, tokens, etc. in the source code. Although it is quite common for Android applications to integrate third party APIs, they may not necessarily be for client-side API calls. When such credentials are exposed in plain text, they form easy targets for password guessing exploits.
Recently, CSC BHIM app suffered a data breach, exposing 70 lakh user records, due to an unsecured AWS database. Developers had allegedly coded AWS credentials into the app itself. In such cases, a static code analysis can debug the source code before the program is executed. It exposes any vulnerability within the static source code. This process is also automatable. However, there can be too many false positives.
Weak Cryptography
Broken cryptography in Android applications uses weak algorithms for encryption and decryption, or implements a strong algorithm in an insecure way.
The widely used cryptographic hash function MD5 has been found to be vulnerable. Stream cipher RC4 is known for its simplicity and yet was discovered to have multiple vulnerabilities.
Finding weaker/vulnerable cryptography could be automated through static analysis.
Using a static analyser in APK
Java decompilers decompile the Java bytecode into source Java code. Using such tools, we convert the APK to produce the source code. Even though they might not be the exact code the developer had written, the classes, methods, and the logic would be the same. This reveals hardcoded credentials or other flaws in the code that the developer may have used.
Most common developer bad coding practice involves custom cryptography which can be broken quite easily.
HTTPS Issues
Transport security is needed when communicating with the server, this is enforced through HTTPS which uses Transport Layer Security (TLS) to encrypt the data. However, several developers inadvertly invalidate this protection. Several apps choose to trust any certificate given without verifying the trust chain. Such code makes through production when developers test the app in a local environment that may have self-signed certificates, they bypass SSL checks intentionally.
SSL verification could be disabled through code such as by establishing a non validating connection through a custom SSLSocketFactory will turn off all SSL validation.
These bypasses could easily be detected through static analysis.
WebView Issue
WebView is a component powered by a browser engine that lets Android applications open web pages inside the application itself. As browsers are exposed to attacks through intents and deeplinks, it is not safe to open untrusted web pages within the application.
For instance, a Twitter user found a WebView bug in ArogyaSetu, which exposed internal files on the local database. The WebView was callable by intent and any app installed on the phone was capable of loading the URL in the WebView. An attacker who has control over the WebView can decide what web page should be opened. If JavaScript is enabled, attackers can execute JavaScript code inside the app, to perform malicious activities.
Insecure storage
Creating files outside the Android sandbox allows users to view or alter the file content, and this could be a major security concern. Attackers exploit exposed sensitive data or app configuration data stored outside the app sandbox in a format that is readable and writable by any user.
Component Misconfigurations
Exported services and activities: If your app has activities that are exported (meaning they can be called by other apps), and is a malicious app it can gain access to personal and sensitive data. But just because services and activities are exported, it does not mean that it poses security risks. Inspecting the code will also help detect the flaw.
Misconfigured content providers: As mentioned earlier, content providers manage secure access to app data. Misconfigured content providers grant access to external applications without restrictions.
Broadcast receivers: These are Android components that allow you to send and receive system or application events such as a battery low message. Scanning the source code can help you identify what the Broadcast Receiver is capable of or how it is triggered. Attackers can exploit this flaw and send unwanted messages without the users consent.
Conclusion
Android core security features such as the application sandbox reduces security issues to a significant extent. But from the flaws discussed above, it should be noted that good coding practices also ensure the security of Android apps. Also:
Secure the communication between your app and other applications.
Scan for vulnerabilities such as hardcoded credentials or weak cryptography.
Store sensitive information within the sandbox/ internal storage.
Request for credentials before providing access to the premium content within the app.
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:
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:
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.
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:
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.
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.
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.
Urban dictionary defines IoT as: an acronym for “Internet of Things”, e.g. everyday objects (such as light bulbs or refrigerators) that can be accessed and possibly controlled via the Internet. The letter ‘s’ in the acronym stands for data and communication security.
Still wondering where the ‘s’ is?
Although the security of IoT devices demands immediate attention, the abundance of these devices has resulted in the lack thereof. There are more than 40 Billion connected devices at present, and every day a significant number of IoT devices are deployed.
Internet routers, smart TVs, watches, refrigerators, speakers, and security systems such as cameras and home automation devices, are the most common IoT devices. Some of the lesser-known examples are smart vending machine services like BigBasket’s BBInsta, smart electricity meters, bluetooth-activated rental scooters such as Vogo and Bounce, and smart RO water purifiers like DrinkPrime. And most of these devices have already become indispensable parts of our lives.
Why is it important to secure IoT devices?
The growing demand for smart devices makes it essential to prioritize its security. However, the following reasons are also notable:
1. Prolonged use:
Unlike other technological devices, connected devices are used for a longer period of time – ADSL Broadband routers released in the late 2000s with software components from early 2000s are still alive and online. However, most of these devices no longer receive security updates.
Credits:https://xkcd.com/1966/
2. Low attack protection:
Most connected devices run on low power and low memory, making it impossible to leverage modern defense techniques, especially against memory corruption vulnerabilities such as buffer overflow. Also, users usually find stack protection, ASLR, etc. disabled.
3. Uncharted terrains:
The security industry’s primary focus is on web/ desktop applications. Thus neglecting the security of a large number of IoT devices.
How to detect vulnerabilities in IoT devices?
There are multiple ways to detect the vulnerabilities in IoT devices. We will explore:
Firmware Analysis
Service Exploitation
Hardware Engagement
1. Firmware Analysis
The advantage of this approach is that it does not require the physical presence of the target device. When we discuss the various ways to detect vulnerabilities in connected devices, I will explain how I discovered a remotely exploitable remote code execution vulnerability in a highly distributed internet router.
Firstly, download the latest firmware from the device manufacturer’s website, often found in the support page related to that device. Manufacturers usually provide user guides with instructions for manual software update or in the case of bricked hardware.
The preferred tool for this approach is binwalk. It is an easy-to-use tool to analyze, for reverse engineering, and to extract firmware images. Moreover, it would work on any unknown binary file. It scans for known file-type signatures within the file, and detects filesystems and known compressed stream types.
Here is a demo of running binwalk on TP-Link Archer C5’s firmware, the default router issued by ACT, Bangalore.
It, then, detects three things within the file:
U-Boot – A bootloader often used in embedded devices,
Some compressed data, and
A Squash FS file system – These are the root filesystem image and data that are mounted on the device. It will contain all the binaries, scripts, and configuration.
To extract SquashFS and other files one can use binwalk itself: `binwalk -e firmware_file` or `unsquashfs`. However, based on the filesystem, one might need to download additional tools to extract the image.
Sample output of the tree command on the extracted directory
If binwalk fails to identify the filesystem or identifies false positives instead, we can also try manual analysis. We will discuss this, later in the article. Now that we have the code and the binaries that run on the device, we can start testing.
Upon running binwalk on the firmware for JioFI 2, it detects a lot of files directly in plain text, that are not enclosed in a filesystem. Further, open the firmware file in a hex editor and search the first few bytes (also called magic bytes). The file will be identified as an FBF (Flash Binary File).
In the event that this doesn’t work, we shall assess whether the file is encrypted using entropy analysis with `binwalk -E`.
Left: Entropy analysis of JioFi Firmware which contains plaintext files Right: Entropy analysis of a Sony Audio system firmware. Notice the low entropy in the beginning and then very high entropy for the rest of the file, which indicates an unencrypted header part, followed by encrypted contents
The presence of encrypted firmware usually means that proceeding further is difficult. In that case, one could try reverse engineering the header to see if the decryption metadata (key algorithm) is in the header. This is highly unlikely.
If the required firmware is not available, or it is impossible to extract anything, there are other ways to proceed.
2. Service Exploitation
An IoT device will have a network interface. So, we can fire up nmap and scan the host for open services.
Routers, for example, have an http server with a web interface for configuration, status information, etc. which is an easy target for bugs.
Sample output of a scan on my previous isp router; outdated software being used
The most important vulnerability to look for during such black box testing in web ui is command injection. A lot of the Web UI functionality is just a wrapper for internal linux utilities like iptables, ping, traceroute, etc.
The actions on the web interface are passed to these utilities as normal parameterized shell commands which can lead to command injection if the input is not sanitized. Apart from this, we should also look for unauthenticated action execution or if any of the pages failed to implement auth checks.
Step-by-step illustration
Here is one such injection I found in a large ISP issued router:
A normal ping request. Notice how the output is the same as a linux ping command output
Ping request with the ip `127.0.0.1 && uname -a`. Command injection!
Once a command injection is executed, we shall escalate that into a full shell access. Usually we will be able to find a telnet binary. If we fail to find the binary in the system, we can download one. Subsequently, start a telnet listener such as this: `127.0.0.1 && /usr/sbin/utelnetd -l bin/sh -p 2512`.
Then, we explore the processes that are running.
We can find a lot of interesting data here, such as the boa http server, the TR69 server which is used by ISP to remotely configure the routers to perform updates/ customer care, the SIP client for voice calls, PPPd Point-to-point protocol client between the device, and the isp
All these files and data expand the attack surface. These binaries and their configuration files determine whether they are custom or off-the-shelf tools. We can leverage reverse engineering toolkits like Ghidra to analyse these binaries and ascertain their susceptibility to memory corruption issues such as buffer overflow or logic bugs.
At this point, we can also explore the filesystem for configuration files or conduct a static source code analysis of the web UI backend. The most prized bugs to seek are remotely exploitable pre-auth RCEs. Also, try to find services that listen on the WAN interface and use that to find a bug.
One of the bugs I found, during this process, was a telnet binary listening on the WAN which used a custom executable/ bin/ login which only worked if supplied with a hardcoded password.
Such low-hanging vulnerabilities are not very rare. Developers often leave hard-coded backdoor passwords exposed. These are a couple of instances that prove the same:
When Developers leave default passwords enabled on the devices, hackers don’t even need vulnerabilities to exploit them. Here is a list of cameras left exposed with default passwords set:
Similarly, we can find routers, printers, security systems, etc. with default passwords enabled.
3. Hardware Engagement
Anticipating a failure, to find vulnerabilities in the firmware or any other running services with black box testing, there are other ways to detect vulnerabilities:
3.1 Serial Interface
Most IoT devices run a full linux kernel on an MIPS or ARM powered box. A serial interface is not uncommon on these types of devices.
Typically, one can find a UART over RS-232 or TTL interface on the chip of the IoT device. An RS-232 interface will have a 9-pin connector, and a TTL interface will have 3-5 pins. The chip, within the outer case, will have instructions regarding the connectors. Use a USB-TTL converter, soldering the connection between the chip and the converter.
A USB-TTL converter. At least three pins RX, TX, VCC should be connected
Then, connect to the serial console and use device admin credentials to log in.
Connecting to the serial console
These interfaces are usually provided by manufacturers to de-brick the device. At the time of booting the device, we have access to additional functionality such as loading firmware over the network.
Once a shell prompt is initiated, we can use techniques discussed previously, for further testing.
3.2 JTAG
In any case, if the device doesn’t run a full fledged OS or the hardware doesn’t provide a serial connection, there is an even lower level approach we could try.
JTAG is another common hardware interface that enables direct communication with the microcontroller on a board. Even though JTAG was initially used by manufacturers to test all the connections on the board, now they are used for low level debugging.
JTAG connection directions are marked on the chip. Otherwise, the spec sheet of the microcontroller/ processor will have details of the same. Solder directly to the JTAG pins on the microcontroller, to access the debugging interface.
Additional device to connect to the JTAG Interface such as this Exploit-Nano hacker tool
3.3 What can you do with JTAG ?
Pause and step through an operation
Inspect memory
Write bytes directly into memory,
Set break-points
Inject code into the process or process memory
Dump the contents of the bootloader
Bypass logins, and so on
What can hackers do after finding bugs in these devices ?
The Mirai Botnet attack
In 2016, security vulnerabilities in brands of security cameras almost toppled the internet. The Mirai botnet launched 623 Gbps distributed denial-of-service attacks on multiple targets. The traffic originated from thousands of such security cameras. The next year its variant, Mirai Okiru, was launched, targeting Huawei routers.
The proliferation of IoT devices has made it almost impossible to handle the increasing number of attacks they encounter.
Invading privacy
Most smart devices are frequently exploited to encroach on the privacy of its users:
Smart speakers are exploited to listen to interactions.
Security devices such as CCTV cameras are abused to gain access to sensitive visuals.
Vulnerabilities in routers can lead to internet traffic being compromised. Hackers can see the sites visited through plaintext DNS queries. Further, they can perform MiTM attacks and steal credentials or sessions. These vulnerabilities also expose internal devices to the attacker, bypassing the NAT firewall and causing severe damage.
Such low-hanging vulnerabilities are not very rare. Developers often leave hard-coded backdoor passwords exposed. These are a couple of instances that prove the same:
