32764/TCP Backdoor Scanning with NINJA PingU

Recently, it was discovered a backdoor that affects several routers. This backdoor, grants remote root shell access without authentication, an exploiting it is as easy as establishing a TCP connection against this port.

I released a new NINJA PingU plugin, called 32764Backdoor, that is aimed at scanning and identifying hosts affected by the 32764/TCP backdoor.

The plugin is already documented in its web page and the code has already been checked in its repository. NINJA PingU is a framework designed for easy plugin development. As we can see below, the logic of the plugin is only about 20 lines, most of the work is carried out by the framework.

// looks for 0x53634D4D and 0x4D4D6353
char *payload="ScMM"; 

// const for the results
const char *vuln = "vulnerable";
const char *patched = "patched";

void onInitPlugin()
{
    openServiceFile();
}

void onStopPlugin()
{
    closeServFile();
}

void getServiceInput(int port, char *msg)
{
    strncpy(msg, "randomdata\r\n\r\n", 22);
}

void provideOutput(char *host, int port, char *msg)
{
    if (strstr(msg, payload) != NULL && synScan == FALSE)
    {
        persistServ(host, port, vuln);
    } else {
        persistServ(host, port, patched);
    }
}

I have also modified the Makefile to build the plugin automatically in each execution. All the commands are paramatrized, to compile a new plugin you just need to modify the first line of the Makefile and include the name of the plugin as follows.

PLUGINS=Simple Service Backdoor32764

Running this plugin within NINJA PingU is very easy, you just need to specify the name of the plugin in the -m (module) flag as follows:

# ./bin/npingu -t 2 -p 32764 1.1.1.1-255.0.0.0 -m Backdoor32764

This will immediately start the scan. A screenshot of the UI running the plugin is shown in Figure 1.

Figure 1. 32764/TCP Backdoor scan.

An analysis was carried out where 11955970 hosts where scanned.  Among those, 7090 hosts where listening to the port 32764 and 61 vulnerable hosts where found. The analysis took about 15 minutes in a 100mbps dsl line. In Figure 2, we show the plot of this data.

Figure 2. Analysis Results.

OWASP NINJA PingU: All Your Embedded Devices Are Belong to Us

I have recently spent some time reading about TCP, Kernel and C. In order to put some of this into practice, and to have some fun, I developed a tool with a simple goal: scanning the Internet very fast and allow people to use it as a framework for whatever they might find useful. As a result of this:

OWASP NINJA PingU: Is Not Just A Ping Utility is a free open-source high performance network scanner tool for large scale analyses. It has been designed with performance as its primary goal and developed as a framework to allow easy plugin creation. It can be downloaded in its home page and its codebase.


I also wanted to work on the widely-mentioned C10k problem on the client-side and read about TCP. There probably isn't any novel research in this project, I just did this because I had fun doing it, and I am writing about it because someone can either find it useful or give me feedback on how to enhance it. Actually, I started working on this as a performance competition with a coworker and thought it was worth to release it. There are more mature projects such as masscan and zmap. I don't know about those, I just wanted to design one from scratch. I work on static analysis, so I am not an expert on neither C nor networking, but I had fun doing pingu.

The rest of the post is divided into two parts. In the first one, I describe some boring stuff about the kind of problems I faced and the workarounds I found when coding NINJA PingU and the kind of things it can and can not do. In the last part, I describe the first plugin I developed for services identification and embedded devices correlation purposes. I carried out and I show some cool throughput benchmarks and statistics about it.

NINJA PingU Architecture

In Figure 1, we show a general architecture diagram of NINJA PingU.

Figure 1. NINJA PingU Architecture Diagram.

As shown above, PingU is divided into 4 main components.

Spotter

It is aimed at discovering alive services. Its speed will determine the maximum scan speed. So, to achieve this with maximum throughput, it uses raw sockets to build SYN packets that are sent to the targeted IP address and port pairs. Creating IP packets and putting those in the Ethernet device avoids the TCP stack overhead of the operating system. The number of spotter threads is variable depending on the wanted speed.

Listener

Its goal is to listen incoming packets and find those corresponding to responses to the spotter. To achieve this, it uses a magic port number and magic ACK seq number to filter ACK packets and uniquely identify responses to the spotter and discard other network traffic. The results (alive services) are given to the connector. It can also be multithreaded for performance enhance purposes.

Connector

This component is aimed at completing the TCP handshake with the alive services and being an interlocutor between the PingU Plugins and the targeted services. To achieve this it uses non/blocking I/O, by means of the epoll() interface of Linux. This involves HTTP Pipelining and asynchronous networking.

Dispatcher

Its aimed at loading the analysis data, creating the agents and loading the plugins that will be used during the analysis. For easily plugin integration, I used dlopen() for runtime dynamic linking the plugin.

Other Stuff

-The usage of the epoll() interface and the build of raw TCP and IP headers  make pingu platform dependent (it currently only works under Linux).

-For synchronization purposes it is used mutexes and semaphores. Also, caches are used to minimize synchronization points.

-For less disk operations, buffered I/O has been used.

-The TCP No-delay algorithm is deactivated to improve networking performance.

NINJA-PingU Getting Started

OWASP NINJA PingU's source code  is available at github, and documentation about it can be found in its home page. the first release can be downloaded here. Building ninja pingu and its plugins can be achieved by running its make file as shown below.

$ wget https://github.com/OWASP/NINJA-PingU/archive/v1.0.tar.gz; tar -xvf v1.0.tar.gz; cd NINJA-PingU-1.0/; ./npingu.sh

Running NINJA PingU

The basic usage is shown below:

$ sudo ./bin/npingu [OPTIONS] targets

     -t Number of sender threads.
     -p Port scan range. For instance, 80 or 20-80.
     -d Delay between packages sent (in usecs).
     -s No service discoverage (less bandwidth load).
     -m Module to run. For instance, Service.
     -h Show this help.
     [targets] Can be a single ip or a range (i.e. 1.1.1.1-255.0.0.0).

root privileges are required to be able to build the raw socket descriptor. For more information, check out the pingu's FAQ and if you still have questions, feel free to contact me at guifre dot ruiz at the owasp dot com server.

NINJA-PingU Plugin: Embedded Device Scanner

Recently, Bruce Schneier wrote about the security risks of embedded systems. To perform a simple experiment, I wrote a PoC plugin for NINJA PingU to identify those.

The plugin is targeted at performing a simple HTTP GET request to the port 80 of the targeted hosts and analyze the Server banner of the response. The plugin is open source and included in the v1.0 package.

The following and several other devices are currently supported.

· Network Cameras

Tones of network cameras, usually security related ones can be found with the Service scanner plugin. Some of them require username and password where the default ones tend to work and others do not require any credentials.

Figure 2. Web Camera Device.

· Network Programmable Controllers

The Network Devices identifier plugin is also capable of finding programmable devices such as the one shown below.

Figure 3. Network Programmable Controller Device.

· Solar Power Plants Management Devices

It is also capable of finding solar power plants management devices. This web service allows you to stop those, start them and perform several critical operations.

Figure 4. Web Camera Device.

· Smart TV Devices

Smart TV devices are also reachable, and the admin console of those have several options, such as loading new frameworks, creating alarms, among others.

Figure 5. Smart TV Device.

 · Network Multimedia Disks 

You can also find several network disks that contain personal data and have full access to those. Also, you can usually get the last movies in theaters.

Figure 6. Network Multimedia Disk.

· GPS Devices

GPS devices can be scanned with NINJA PingU. Though, these usually require user and password, the default ones tend to work. These devices are targeted to the agriculture and construction industries and contain interesting sensors attached to those.

Figure 7. Industrial GPS Device.

 VoIP Phones

Some ranges contains hundreds of VoIp phones services. These services have several personal data.

Figure 8. VoIP Phone Service.

· Network Printers

Several network printers can be found with NINJA PingU. These usually do not require user and password and they contain sensitive information such as printed documents, and personal information in the fax functionality. Above we show a screenshot sample.

Figure 9. Printer Web Service.

 · Central Communication Devices

NINJA PingU also identifies industrial central communication devices targeted at building automation and energy efficiency among others.

Figure 10. Central Communication Device.

 Restaurant Management Services

NINJA PingU is also able to identify Restaurant Management Services. These allow you to change prices of the food, download client lists, see the current waiters, change settings, book tables, etc..

Figure 11. Restaurant Management Service.

 Measurement Control Data Logger Devices

The Service discoverage plugin also identifies some data logger devices  that provide some information of temperature and some data of the devices attached.

Figure 12. Measurement Control Data Logger Device.

.

Performance Experiment

To test the NINJA PingU's performance the following experiment was carried out.

The experiment setup was made in my home laptop, in a 100mbps network, an analysis from targeting 74.1.0.0 to 74.150.1.1 (about a million hosts). We targeted the port 80 in those hosts to identify web servers. Only one thread was used, increasing it made my router to crash.

As shown in Figure 13, the scan took about 18 seconds and 1 million hosts were scanned and 10 thousand replied with an HTTP Message.

Figure 13. NINJA PingU Performance Plot.

On average, more than half million services were scanned every second and more than 5 hundred were found every second.

Unfortunately, network bandwidth was a huge bottleneck, if you happen to have access to a better network and you carry out some scan I will be very glad to hear you thoughts.

If you find this interesting or not interesting I will be very glad to hear about it.