OUSPG

[This page is CSS2 enabled. Your browser might not fully support it]

PROTOS Test-Suite: c04-wap-wsp-request

$RCSfile: index.html,v $ $Revision: 1.157 $ $Date: 2001/05/20 20:40:27 $

Permission is hereby granted for quoting, reprinting and redistributing
this document, provided that a link to this document is given, and all
changes made are clearly separated from the original text.

ABSTRACT

WAP is a worldwide standard for providing Internet communications and services on wireless terminals. It has been adopted in the infrastructure of some digital mobile phone networks. A subset of the WAP suite, namely WSP request, was chosen as the subject protocol and software vulnerability analysis through syntax testing was conducted. A survey of the related standards was made, existing implementations were identified and targets were chosen. Test-material was prepared and tests were carried out. Results were gathered and reported. Many of the implementations available for evaluation failed to perform in a robust manner under the test. Some failures had information security implications, and should be considered as vulnerabilities. To promote and support securing WAP implementations this test-material should be adopted in evaluating and developing the products.

Table of Contents

• ABSTRACT
• Table of Contents
• Introduction
• Analysis
• Design
  • Standard survey
  • Subject survey
  • Injection vector survey
  • Specifications Design
  • Anomaly Design
• Injection
  • UDP injector
• Instrumentation
• Implementation
  • Results from the test-runs
  • Verification via exploits
• Test-material package
  • Package information
  • License and copyright
  • Usage
    • Using with Java
    • Using single test-cases
  • Download
  • Notes
• Conclusions
  • Acknowledgments
• Vulnerability management
  • Prior public vulnerabilities
  • The vulnerability process
  • Advisories and vendor statements

Introduction

This test-suite is a byproduct of the "PROTOS - Security Testing of Protocol Implementations" project. Important: Background, goals, limitations, terminology and licensing for this test-suite release are explained in the "Test-suite releases in Theory and Practice" document.

This test-suite covers a limited set of information security and robustness related implementation errors for a subset of the chosen protocol. The subject protocol and the chosen subset of it are illustrated in the "Analysis" section below.

Analysis

"WAP - The de facto worldwide standard for providing Internet communications and advanced telephony services on digital mobile phones, pagers, personal digital assistants and other wireless terminals." [http://www.wapforum.org/]

"The WAP specification pulls together existing technologies and defines new standards to provide subscribers with: ... Peace of mind that all transactions are completely secure. ..." [ http://www.wapforum.org/what/WAP_white_pages.pdf]

In the initial analysis the WAP suite was chosen as the focus area for this test-suite. The factors behind this selection included:

• WAP is a rather new family of protocols and their implementations, thus we should be able to see if classic vulnerabilities still emerge.
• WAP is very similar to HTTP, giving us a past history of vulnerabilities in implementations of a similar protocol.
• WAP enables new forms of e-commerce and new services are emerging. Early scrutiny may lessen the potential financial losses.
• WAP bridges traditionally robust and critical communication infrastructure with the open Internet.
• WAP has been adopted by operators in their mobile phone networks as well as by smaller organizations for their customized services and pilots.
• WAP has interesting complexity for further improving the testing tool.

The protocol suite was further narrowed down to one specific protocol and protocol data unit type, namely Wireless Session Protocol (WSP) and request PDU. Rationale behind the selection:

• WSP request PDU manifests in the initial communication with the servers, gateways and proxies.
• Neither dynamic behavior nor state requirements have to be considered in basic testing.
• Interface for entering the WSP request PDU is by design exposed to all users of the protocol.

Design

Standard survey

The available standards specifying the selected protocol have to be studied, and analysed. The relevant protocol specifications specifications are listed in the table below.

Specification for the WAP WSP request PDU was found.

Subject survey

A thorough survey of the available implementations is conducted. This should include a diverse selection of implementations in order to gain a better insight into the applications implementing the protocol, and to give a hint of the impact of the potential vulnerabilities. Typically, not all implementations are available for testing, and thus cannot be tested by the project personnel within this test-suite prerelease phase.

A subset of the implementations was chosen to be tested during the test-suite creation and prerelease phases.

Injection vector survey

The injection vector, or delivery vector, survey analyses the different methods of delivering the test-cases to the implementations under test. Often, there are several methods of injection and the test-suite cannot cover them all, or might miss some vectors not available in all implementations.

The reason for using UDP was simple. The only other option would have been SMS which is both slow and expensive. Also injection code for the UDP delivery already existed in the developed test-tool framework.

Connectionless mode was chosen because of its simplicity. If connection oriented mode was used, it would have required a WTP implementation and more complexity for WSP (Connect/Disconnect features).

The chosen delivery vector (udp port 9200) may be open either on the side exposed to mobile users, the Internet or both.

Specifications Design

Protocol data unit specifications are used as a basis for generating the test-cases. Starting point for the design of the test-suite is to acquire or create a machine-readable representation of the protocol specification. The test-tool developed in this project uses a custom dialect of BNF (Backus-Naur Form). BNF is capable of describing context-free syntax of a specification, which is not generally enough for PDU generation. The specification is completed by some semantic extensions in BNF and embedded Java-coded functions.

In this test-suite a BNF was needed for the WSP requests in connectionless mode. The available WSP specification does not specify the PDU structures in BNF format. Only HTTP headers are specified in Augmented BNF, but the WSP specification way of writing Augmented BNF was incompatible with the test-tool and thus needed modifications for our use. The subset for this test-suite was further reduced by ignoring header fields that are sent from the WAP gateway to the direction of the mobile phone.

Anomaly Design

Anomalies are the changes in the normal communication packets, which might cause undesired effects in the implementations. Some of the anomalous cases are not malformed but follow the specification, and might still be inputs that have not been considered when implementing the software. The design of anomalous test-cases is done with the test-tool configuration files. These anomalies aim to reveal the undesired behaviour and do not contain any vulnerability exploits running arbitrary code on the tested implementations, even where it would be possible.

In this test-suite, these include anomalies and combinations of anomalies in length field values and in string field values themselves. Missing or repeated delimeters can also be considered as anomalies.

Following anomaly types were integrated:

String anomalies

String anomalies consist of multiple ASCII characters "a" (0x61). Amount of characters varies from 2 to 64000. The whole range is not included, only the most likely lengths to cause trouble. In case of expected ASCIIZ values the null termination may be omitted.

Length anomalies

Length anomalies include integers in UINTVAR form. The most of those integers are common boundary values, but also robustness of UINVAR->UINT decoder required in WAP Gateway is tested by flooding byte 0x80 (when MSB is 1 in UINTVAR byte it indicates that the UINTVAR field continues in the next byte).

Delimiter anomalies

The last and least used anomaly is URL-delimiter anomaly. For URL-delimiters incorrect delimiters like (";//", ":"+1000x"/") were tried to test the robustness of URL parser.

Injection

The injectors implement the chosen delivery vector. Suitable injectors already integrated in the test-tool framework are reused.

UDP injector

In this test-suite the WSP protocol datagrams are injected to WAP gateway using UDP protocol. Corresponding UDP injector was utilized.

Instrumentation

With instrumentation on the target platform we are able to monitor for undesired behavior of the subject implementation. Typically this manifests as exceptions or signals such 'access violation' and 'segmentation fault'.

No instrumentation will be bundled with this test-suite release. Observing any undesired behavior relies solely on the tools and logging provided by the target platform. Unfortunately the modern trend of abusing the try-catch -type of constructs easily masks the exceptions generated by stack and memory corruption. Catching these hidden exceptions relies on the debugging skills of the developers themselves.

Implementation

Test-runs were conducted against the chosen subject implementations. Packet specifications, desired anomalies, injectors and instrumentation were integrated as a test-tool configuration to enable automatic execution of the tests.

Results from the test-runs

The results of the test-runs, derived from the test-logs, are presented in the table below. Product names of the actual subjects are omitted to protect the innocent. Results are presented in a tabular form with test-cases divided into subgroups based on the anomaly types utilized and PDU fields under examination.

Legend:

• A1: string anomalies in use?
• A2: length anomalies in use?
• A3: delimeter anomalies in use?
• tr-nnn: Each different test-run (tr-nnn) represents a different tested implementation.
• X: Verdict is failed - undesired behaviour observed
• ?: Verdict is inconclusive - potential problem area - unverified
• -: Verdict is pass - no undesired behaviour observed

The results are further summarized below.

Each fail verdict is due to an exception, signal or unexpected exit. Each of them represents minimum of a denial of service type vulnerability. In most cases they represent memory corruption, stack corruption or other fatal error condition. Some of these may lead exposure to typical buffer overflow exploits, allowing running of arbitrary code or modification of the target system.

Verification via exploits

To support the vulnerability reporting process, typically one exploit per implementation is refined and included in the respective vulnerability report. The exploit is only intented for demonstration purposes and is harmless as it is. Simplest of them only execute some harmless commands in the target system, typically with the privileges of the vulnerable process. Some only provide a demonstration by causing a Denial of Service (DoS) against the service.

To support the vulnerability reports to vendors, following exploits were developed:

• Buffer overflow exploits allowing execution of arbitrary code were demonstrated against four WAP gateway products.
• Denial of service exploits were demonstrated agaist remaining three WAP gateway products under evaluation.

Test-material package

Package information

Test-material is distributed as a JAR-package. This package comprises of the following elements:

• Total of 4236 test-cases (PDUs), located in testcases/ directory
• Java code (source and compiled) for feeding the test-cases against the system under test.
• LICENSE.TXT - GNU General Public License (GPL) version 2
• README.TXT - Instructions

License and copyright

The test-material is licensed under GNU General Public License (GPL) version 2, at no charge. This is done in order to ensure that vendors and their customers may freely utilize the test-material. Standard GPL terms for no warranty and no liability apply.

We recommend some additional guidelines, although these do not restrict the test-material license. These guidelines can be found from the "Test-suite releases in Theory and Practice" document.

Usage

The test-material can be used either with the bundled injection code [Using with Java] or with an external injector [Using single test-cases].

Using with Java

Java Runtime is a prerequisite for running the bundled Java code. [http://java.sun.com] This package has been tested on Java 2 SDK 1.2.2. [ http://java.sun.com/products/jdk/1.2/].

Usage examples for the injection code bundled in the JAR-package:

java -jar c04-wap-r1.jar -help

This command displays the built-in help for the available command line options. Options such as selecting a specific range of test-cases or non-standard destination port are high-lighted therein.

java -jar c04-wap-r1.jar -host 10.10.10.10

This command activates the bundled injection code and test-cases are delivered to the system under test one by one. Target system is identified either by host name or ip-address.

Using single test-cases

The test-cases (PDUs) are in raw binary format and can be used by any suitable delivery software, such as netcat. The individual test-cases can be extracted from the JAR-package with tools such as unzip, winzip or jar. Refer to the manual pages and product documentation of the respective tools for additional information.

An example delivery with netcat:

netcat -u 10.10.10.10 9200 < testcases/00000999

Download

• c04-wap-r1.jar - Test-material Release v1
• c04-wap-r1.jar.asc - Detached PGP signature

Notes

Presence of a web server on the target machine may affect the test reproducibility. This is due to an embedded http://127.0.0.1 URL in the test material. Results presented herein were obtained without a web server running on the system under test.

Conclusions

Many of the WAP gateway implementations available for evaluation failed to perform in a robust manner under the test. Some failures had information security implications, and should be considered as vulnerabilities.

To promote and support securing WAP implementations this test-material should be adopted in evaluating and developing the products.

Acknowledgments

We wish to express our gratitude to individual vendors who worked with us to protect their customers. We acknowledge the effort made by the Oulun Puhelin (OPOY) in attempting to acquire us WAP gateway implementations for evaluation. Last, but not least, we are grateful to AusCERT for their patient help, advice and active role during the vulnerability process.

Vulnerability management

Prior public vulnerabilities

The most common sources for vulnerability information and exploits were covered and cross checked for potential and already known vulnerabilities in the implementations of the chosen protocol. Typical sources for finding out about existing vulnerabilities are databases and mailing-lists. Search-engines may also reveal information on past vulnerabilities.

Search for already known and relevant WAP gateway vulnerabilities yielded no results.

The vulnerability process

During the prerelease phase all verified vulnerabilities were reported to the respective vendors. The vulnerability reports are tracked by the AusCERT in role of an independent coordinator and advisor. An attempt was made to seek a channel to distribute the test material to vendors whose products we were not able to obtain for testing. A grace period of over 45 days was kept between the vendor notification and public release.

Advisories and vendor statements

Vendor statements or security advisories issued in order to address the vulnerabilities uncovered by this test-suite are collected. Advisories that we are aware of are listed here-in:

Kannel [Wapit] [2000-10-17]

"Kannel was vulnerable to this denial-of-service attack. The vulnerability has been corrected in release 0.10.1 of the 0.10 series, release 0.11.1 of the 0.11 series, and is not present in the newly released version 0.12.

There is no risk of further intrusion associated with this bug. That is, this was not a "buffer overflow" problem which could be exploited to gain access to the system."

- Richard Braakman [Wapit]

AusCERT Newsletter, Vol. 4, Num. 4 - Jan 2001 [2001-01-03]

... "Vendors with existing products and vendors developing new implementations of WAP gateway servers may wish to take advantage of independent test material such as this suite available from PROTOS, and run it against their own software. A successful result is not in itself a guarantee of security, but vendors can utilise their results as a benchmark from which to develop further test procedures that will enhance the security of their products." ...

No other statements as of 2001-05-20

As of 11th of October 2000 we are aware that five out of seven vendors involved have addressed the security implications brought up by this test-suite with fixed builds of their products. Four out of five releases have been verified to survive the test-material as it is.

[This page is CSS2 enabled. Your browser might not fully support it]