Category: Vulnerability

 

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.

 

Example

Test URL: https://vulnerable.site/somefile.php?file=validpdffile.pdf

To 

Attacking URL: https://vulnerable.site/somefile.php?file=../etc/passwd

 

Server Side Request Forgery

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.

 

Example

Test URL: https://vulneralbe.site/somefile.php?filetocall=https://external.site/somefile.js

To

Attacking URL: https://vulneralbe.site/somefile.php?filetocall=file:///etc/passwd

 

SQL Injection

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.

 

Example

Test URL:https://targetsite.com/somefile.php?id=2

However, if the web application does not validate the user input, the attacker can submit something like this:

Attacking URL: https://targetsite.com/somefile.php?id=’ OR ‘1’=’1’–+

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. 

 

The ‘S’ in IoT

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.

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:

1. U-Boot – A bootloader often used in embedded devices,
2. Some compressed data, and 
3. 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.

This firmware uses squashFS, but there are other file systems used in embedded devices that one could use: [https://elinux.org/File_Systems#Embedded_Filesystems]

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.

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`.

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. 

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: 

 

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.

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:

https://securityledger.com/2015/08/hardcoded-firmware-password-sinks-home-routers/

https://nakedsecurity.sophos.com/2013/10/15/d-link-router-flaw-lets-anyone-login-using-joels-backdoor/

https://jalalsela.com/hacking-tp-link-tl-wr740n-backdoor/

 

Command injection bugs are also very common: 

https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/under-the-hood-linksys-remote-command-injection-vulnerabilities/

https://www.cybersecurity-help.cz/vdb/SB2019040101

https://packetstormsecurity.com/files/145823/TP-Link-Remote-Command-Injection.html

 

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:

https://www.shodan.io/explore/tag/camera. 

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.

Then, connect to the serial console and use device admin credentials to log in.

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. 

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.