Oulun yliopisto - Etusivulle University of Oulu in English

ee.oulu.fi

Electrical and Information Engineering

University of Oulu > Faculty of Technology > Electrical and Information Engineering


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

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.

standard-survey
Standard Date Organization Status Link Description
WSP 20000710 WAP Forum Closed http://www.wapforum.com/ Official WAP WSP Protocol specification

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.

subject-survey
Subject name License Platform Link to source
Apion WAP gateway commercial ? (link)
audicode WAP gateway commercial NT (link)
Celtius WAP gateway commercial ? (link)
CMG Asia Wap gateway commercial Custom HW? (link)
Ericsson WAP gateway commercial Custom HW (link)
eXaflow WAP gateway (HW) commercial Custom HW (link)
GNU Wap Server GPL Unix (link)
Infinite WapLite commercial NT (link)
Integra Jataayu Wap Server commercial NT+Unix (link)
Jinny commercial unix (link)
Kannel BSD Unix (link)
Kuulalaakeri WAP gateway commercial Unix (link)
Materna Carrier WAP gateway commercial Custom HW? (link)
Mobileways WAP gateway commercial Custom HW? (link)
Nokia Artus Messaging Platform commercial Custom HW (link)
Nokia WAP server commercial NT (link)
Ophelia Open source NT+Unix (link)
Oracle Portal2Go commercial NT (link)
Peramon Wap Gateway commercial NT+Unix (link)
Phone.Com WAP gateway commercial Custom HW (link)
RealWoW WAP gateway commercial NT (link)
zTango WAP gateway commercial Custom HW (link)
SASi Wap Gateway commercial NT (link)
Tantau WAP server commercial NT+Unix (link)

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.

injection-vector-survey
Application protocol Transport protocol Packet
WSP UDP Connectionless request to port 9200
WSP+WTP UDP Connection oriented requests to port 9201

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.

Verdict per implementation for each anomaly group
Category A1 A2 A3 tr-001 tr-002 tr-003 tr-004 tr-005 tr-006 tr-007
accept-string-overfow yes no no - - - X - - -
accept-string-overfow-len yes yes no - - - X - - -
accept-charset-string-overflow yes no no - - - - X - -
accept-charset-string-overflow-len yes yes no - - - - X - ?
accept-language-string-overflow yes no no - - - - X - -
accept-language-string-overflow-len yes yes no - - - - X - X
accept-ranges-overflow yes no no - - - - X - -
accept-string-overflow yes no no - - - - X - -
accept-string-overflow-len yes yes no - - - - X - -
authorization-passwd yes no no - - X - - - -
authorization-userid yes no no - - X - - - -
cache-control yes no no - - - - - - -
connection yes no no - - - - - - -
post-data yes no no - - - - - - X
post-data-headers-len yes yes no - X - X - X -
post-data-url-len yes yes no X X - X - X X
referer yes no no - - - - - - -
url-delimiter-headers-len-in-post no yes yes - X - X - X X
url-delimiter-in-get no no yes - X - - X - X
url-delimiter-in-post no no yes - X - - - - X
url-delimiter-len-in-get no yes yes X X - X - X -
url-delimiter-url-len-in-post no yes yes X X - X - X X
url-file-headers-len-in-post yes yes no - X - X - X X
url-file-in-get yes no no - - - - - - X
url-file-in-post yes no no - - - - - - X
url-file-len-in-get yes yes no X - - X - X -
url-file-url-len-in-post yes yes no X X - X - X X
url-host-headers-len-in-post yes yes no - X - X - X X
url-host-in-get yes no no - X - - - - X
url-host-in-post yes no no - X - - - - X
url-host-len-in-get yes yes no X - - X - X -
url-host-url-len-in-post yes yes no X X - X - X X
url-protocol-headers-len-in-post yes yes no X X - X - X X
url-protocol-in-get yes no no - X - - - - X
url-protocol-in-post yes no no - X - - - - X
url-protocol-len-in-get yes yes no X X - X - X X
url-protocol-url-len-in-post yes yes no X X - X - X X
user-agent yes no no - - - - - - -
zero-items no no no - - - - - - -

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.

testrun-results
Testrun Total testcases Failed testcases Total anomaly groups Failed anomaly groups
tr-001 4236 569 39 10
tr-002 4236 141 39 18
tr-003 4236 10 39 2
tr-004 4236 385 39 16
tr-005 4236 664 39 8
tr-006 4236 622 39 14
tr-007 4236 148 39 20

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

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]