OUSPG

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

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 WMLC content, 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 hardening WAP WMLC implementations this test-material should be adopted in the evaluation and development of these products.

Table of Contents

• ABSTRACT
• Table of Contents
• Introduction
• Analysis
• Design
  • Standard Survey
  • Subject Survey
  • Injection Vector Survey
  • Specifications Design
  • Anomaly Design
• Injection
  • ServerSocket Injector
• Instrumentation
• Implementation
  • Results from the Test-Runs
  • Verification via Exploits
• Test-material Package
  • Package Information
  • Licence 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
• Appendices

Introduction

This test-suite is a byproduct of the "PROTOS - Security Testing of Protocol Implementations" project. Important: Background, goals, limitations, terminology and licencing 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, and an earlier c04-wap-wsp-request had shown us that classic vulnerabilities still emerge in the implementations of at least one subset of the protocol suite. Further study was deemed sensible in order to validate this observation.
• Reasoning made during c04-wap-wsp-request test-suite still applies. WAP is used in critical communication infrastructure and for e-commerce. Early scrutiny may lessen the potential financial losses.

The protocol suite was further narrowed down to one specific protocol, namely Compiled Wireless Mark-up Language (WMLC), thus yielding protocol data units in form of WMLC content. Rationale behind the selection:

• Earlier c04-wap-wsp-request test-suite was aimed against server side implementations. This test-suite attempts to address an another important link in the chain, ie. WAP WMLC client software.
• This area is important since WAP WMLC clients are mainly extremely homogeneous embedded devices deployed in large quantities. Possibly this is the first time such a vast number of potentially exploitable installations with so little diversity have been interconnected.
• If patch deployment for vulnerabilities in traditional client software has proven problematic, then patching them in embedded consumer appliances already in the hands of the customers may pose even further challenges.
• WAP terminals are ready to accept and process WMLC content by design. Currently it has to arrive as a reply to a request, e.g. as the retrieved page from a content server, or in the future (WAP 1.2) provided as server push content.
• WMLC was chosen over WML since it is already in compiled form and will pass unaltered through a typical WAP gateway implementation. This is relevant since our focus is on the terminal robustness, not on how gateways handle compilation of WML into WMLC.

"... The company (Nokia) expects the market of Internet-enabled handsets to reach about 60 million in 2000, of which WAP-enabled handsets would represent approximately 40 million. For 2001, Nokia estimates that web-enabled handset unit volumes will increase to around 200 million with WAP handsets representing some 180 million of the total. ..." [ http://press.nokia.com/PR/200012/800970_5.html]

Design

Standard Survey

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

WMLC is basically an encoding scheme specified by WBXML (WAP Binany XML content format) specification. The goal of WBXML is to reduce amount of data to be transmitted by encoding XML documents into binary form. As WML is derived from XML, WBXML rules can be applied to WML documents and the result is WMLC document.

Subject Survey

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

Note, that embedded devices from different manufacturers may contain same outsourced implementation of a WAP browser.

Injection Vector Survey

The injection vector survey, or delivery vector survey, analyses the different methods of delivering the test-cases to the implementations under test (IUTs). 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.

Each option involving Wireless Session Protocol (WSP) has choice of using connection oriented mode (WTP) or connectionless mode. Connection oriented (CO) mode was used if the WAP terminal supported it, otherwise connectionless (CL) mode was used. WTP was provided by a WAP gateway.

WTLS (Wireless Transport Layer Security) was not used for the test-case delivery. It only affects the transport and is not relevant when focusing on the WMLC parser implementations.

For the test-runs WMLC+HTTP+WSP+[WTP] and WMLC+HTTP delivery combinations were chosen, first one requiring presence of a WAP gateway.

These selections for the delivery vector provided for succesful injection against all available implementations.

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). The BNF is capable of describing context-free syntax of a specification, but is not usually 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 presentation of a typical WMLC document was required. The available specifications don't specify WMLC document structures in BNF but in XML. Thus, the specification was converted to our dialect of BNF.

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, but might still be inputs that have mpt 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.

The following anomalies were integrated:

Legend:

• Category column describes what kind of anomalies are integrated in the test group.
• Selections column describes how many test-cases belong to the test group.
• See the table below for explanation of different anomaly types.

Injection

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

Test-run automatisation was desired due to large number of test-cases and manual labour required to instruct the browsers to fetch all the test-cases. This goal was achieved through the WMLC timer attribute. Each WMLC deck (test-case) was given a timeout of one second. After the timer expires, subject performs WSP GET request ad receives the next test-case. However, this might not always work because the subject sometimes is unable to parse the WMLC deck it fetched. In those cases manual "refresh/reload" operation is required to fetch the next test-case.

In this test-suite the WMLC content is injected as a HTTP reply over TCP. When possible the WAP browser under test was configured to fetch the content directly. In the typical cases (mobile phone hardware) a WAP gateway was required to act as an intermediate converting HTTP reply into WSP reply. See the figure below for conceptual illustration of the injection vectors (A, B and C alternatives).

Figure: Injection vectors illustrated

ServerSocket Injector

Corresponding ServerSocket injector code was utilised and it acted as a HTTP server providing WMLC content.

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

NOTE: The results were collected by using the prerelease 1 version of the injector. Value of zero (which is default) for the '-closedelay <millisec>' parameter for the prerelease 2 JAR should correspond to the prerelease 1 test results. Try the latest test-material package also with different values for the close delay.

Results from the test-runs are summarised herein. Tables below represent the observations from feeding the test-material against chosen subject software. 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 utilised and PDU fields under examination.

Legend:

• tr-nnn: Each different test-run (tr-nnn) represents a different tested implementation.
• X: Verdict is failed - System crashed / restarted itself
• H: Verdict is failed - System hung
• E: Verdict is failed - An "effect" was seen on system before crashing
• S: Verdict is failed - WAP browser stopped working
• -: Verdict is pass - no undesired behaviour observed

The results are further summarised below.

Each fail verdict is due to an exception, signal or unexpected exit. Each of them represents a 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. The 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 software.

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

• A buffer overflow exploit allowing execution of arbitrary code was demonstrated for a phone similator. The implementation in question appeared to be a cross-compilation, for the PC platform, of the corresponding phone software. This can be taken as an indication of the exploitability of the embedded version as well.
• A buffer overflow exploit allowing execution of arbitrary code was demonstrated on the PC platform for a cross-platform browser available for phones, PDAs and PCs.
• Denial of service exploits were demonstrated against remaining eight WAP WMLC implementations. Some of them displaying phone corruption that resulted in reinitialization and loss of stored data.

Test-material Package

Package Information

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

• Total of 1033 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

Licence and Copyright

The test-material is licenced 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 utilise 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 licence. These guidelines can be found from the "Test-suite releases in Theory and Practice" document.

Usage

Prerequisites for using the test-material are:

• A configured WAP browser is required. (check by browsing alternative WAP content)
• If the browser doesn't support direct HTTP then a configured WAP gateway is required. (check by browsing through the WAP gateway)
• Network connectivity for the browser platform, typically in cases of the mobile phones it comes in form of a PPP dial-up to same address space where the WAP gateway is located. (check by browsing through the WAP gateway)

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 c05-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 c05-wap-r1.jar

This command activates the server mode. It starts a fake HTTP server on the port 8000 which replies to requests for WMLC content (test-cases). Now pointing the WAP browser to URL http://<machine-with-jar-running>:8000 should initiate the test-run.

Using Single Test-Cases

The test-cases (PDUs) are in raw binary format and can be used by any suitable delivery software, such as a WWW-server (e.g. Apache). 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.

After extracting test-cases you can copy them to the content directory on your WWW-server. Note that the WWW-server must support mime-type application/vnd.wap.wmlc. If you use Apache, adding the following mapping into the mime.types should be sufficient:

application/vnd.wap.wmlc           wmlc

After proper WWW-server configuration you should be able to fetch WMLC pages from your WWW-server. If your WWW-server is for example located on 10.10.10.133, requesting URL http://10.10.10.133/00000023.wmlc in your WAP browser should return test-case #23.

Download

• c05-wap-r1.jar - Test-material
• c05-wap-r1.jar.asc - Detached PGP signature

Notes

Timer based test-run automation will not work if you are not using the Java based injection code bundled with the test-material. This is due to the test-cases initiating a fetch of a preset URL.

The WAP gateway utilised as part of the delivery vector while collecting the test-results presented herein was the Kannel version 0.10.2 (http://www.kannel.org).

In prerelease 2, a parameter for setting a delay before closing the socket was added to the injector (and thus the '-closedelay <millisec>' parameter the prerelease 2 JAR). This was required due to apparent asynchronous handling of closed connection prematurately terminating the case processing in some implementations of WMLC.

Conclusions

The test results are a sad reading. None of the target browsers survived the c05-wap-wmlc test-suite. Some of the browsers survived on WMLC that decently working WAP gateway would produce from WML, but exceptional WMLC created in this test suite caused failures even in these subjects.

Acknowledgments

We acknowledge the effort made by the Oulun Puhelin (OPOY) in acquiring us hardware implementations of the WAP browsers for evaluation. We thank Tuukka Turunen from Nexim Oy for providing us PDA type mobile phone test subjects 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 browser 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 is 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 15 months (since Feb'2001) was kept between the vendor notification and public release (May'2002).

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:

• None as of 2002-05-15

Appendices

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