WAP and Mobile HTML Basics
Wireless Application Protocol provides a method to access the Internet from mobile devices. WAP architecture includes a few items, such as a WAP browser on the mobile device, the destination application/HTTP web server, and a WAP gateway in between the mobile device and the application/HTTP web server. A WAP gateway is an entity that acts much like a proxy server between a mobile device and the HTTP server. Its job is to translate content from web applications in a form readable by mobile devices, such as with the use of WML.
WAP has two major versions: WAP 1.0 and WAP 2.0. It should be noted the WAP gateways are required in WAP 1.0 but are an optional component in WAP 2.0. Figure 1 shows a WAP architecture.
Figure 1. WAP architecture
In the early days of WAP, which used WAP 1.0, Wireless Markup Language (WML) was solely supported. WML was based on HTML, with limited to no support for cookies. WAP websites heavily relied on WML to display content to users, but quickly ran out of all the bells and whistles that users/developers desired. About four years later, WAP 2.0 was established. WAP 2.0 supported more items that make the web experience similar to the PC, such as xHTML, CSS, TLS, and wider support for cookies. Furthermore, WAP 2.0 no longer required a WAP gateway, which alleviated some security concerns with WAP 1.0 (discussed in the WAP 1.0 section). As the industry continued to evolve, so did mobile devices. Nowadays, WAP 2.0 and Mobile HTML sites dominate mobile web applications. Mobile HTML sites are slimmed-down versions of tradition web applications, but viewable on devices with limited view screen and storage capacities (usually with a smartphone or PDA).
Authentication on WAP/Mobile HTML Sites
One of the many problems that WAP and Mobile HTML developers have with mobile devices is the keyboard. PDA-style phones come with a mini-keyboard that looks similar to traditional keyboards, containing letters A–Z and support for every number (0–9) and many special characters by using a SHIFT-style key (see Figure 2).
Figure 2. PDA-style keyboard
On the other hand, non-PDA phones have the traditional 0–9 keys only, with letters above numbers 2–9 and special character support under number 1 or 0 (see Figure 3).
Figure 3. Non-PDA-style keyboard
In order to create a better and easier experience, mobile WAP/Mobile HTML sites have introduced the use of a mobile PIN, which replaces the password; however, this also lowers the security of the authentication process. For example, many WAP/Mobile HTML sites allow a phone to be registered to an account. After a phone is registered via a web application, the mobile phone number can be used instead of a username, and a mobile PIN can be used instead of a password. Unlike traditional passwords, the mobile PIN can only be numbers and is usually four to eight values in length (with at least one major bank limiting PINs to only four numeric values only). The use of a numeric-only value for the PIN increases the user experience by significantly reducing the amount of keypresses to use the mobile device (the same idea holds for the username, by the use of a numeric phone number instead of an alphanumeric username). In either case, when the username is replaced with a phone number and the password is replaced with a PIN, the user experience is improved, but security is reduced. In this use case, a site that usually takes a unique username and strong password has just been reduced to a phone number and numeric value. Although low tech, an attacker could simply enter several phone numbers to see which ones are registered to use the WAP/Mobile HTML site. Furthermore, most WAP/Mobile HTML sites give verbose error messages (again, for a strong user experience but bad security practice), so entering the incorrect mobile number will let the attacker know that a number has not been registered. The attacker can then enter the next number on their list until they receive an error message that states the PIN is not correct instead of an error message that says the phone number is unregistered. Once they have identified a valid phone number that has been registered already, the attacker now has to brute-force the PIN.
Admittedly, brute-forcing a weak PIN is not the full responsibility of the banking/e-commerce site, but how many users will simply use “1234” if they are required to have numbers only and four values? Further, how many users will simply use their seven-digit phone number as the password, which still fits into the number-only restriction of four to eight values. The examples could go on, but with a key space drastically reduced from A–Z, 0–9, and special characters to 0–9 only, the likelihood of an attacker hijacking a user’s account by brute force significantly increases. A possible mitigation to brute-forcing weak PINs is for the organization to enforce a password policy different from its online web application. For example, the organization could mandate that the account is locked out after three failed attempts. It could also reject physical keypad sequences such as 2580 and repeating numbers, and it could restrict certain numbers such as the seven-digit phone number or the last four digits of the phone number. Each of these steps would help reduce the basic brute-force attack from being successful.
It should be noted that some WAP/Mobile HTML sites provide limited functionality, often just one or two functions with little account information available; however, the ability to buy/sell items or transfer dollars is available in most of these sites, and this is likely to increase in functionality rather than decrease (at least one major bank has full functionality with only a four-digit number PIN). Regular PC-based banking/e-commerce websites had very limited capabilities as well when they were first introduced and quickly blossomed into full-fledged web applications, but the enforcement of strong authentication lagged behind here too.
Adding to the “user experience versus security tradeoff” theme, another avenue of exposure is the crossover use of SMS and WAP/Mobile HTML applications. For example, some WAP/Mobile HTML sites allow the use of SMS to retrieve sensitive information. The general idea involves using a predefined destination number (registered earlier in the web application) and sending messages with specific words in them, such as balance, transactions, history, status, and accounts. The receiving entity then returns specific information back to the user, based on the request. Obviously, the use of SMS is important if non-PDA phones are used because e-mail is not really a strong option. After a mobile device is registered (that is, the user has registered their mobile phone number and a correlating PIN using the regular web application), the site allows the user to send SMS messages to a specific number and retrieve certain data, such as account balances and transactions. During this process, a user is not challenged with a user ID or password/PIN, but is simply verified with the caller ID value. For example, sending an SMS message to a predefined number (assigned by the bank or e-commerce organization) will return an account balance as long as the caller ID value is correct.
The key control here is the caller ID, which is thought of as a trusted value. However, a simple search on spoofing/faking an SMS message will turn up a lot of results (this can also be done using an Asterisk PBX). Hence, if a handset/phone number has been registered to receive/send information using SMS, an attacker can simply spoof the caller ID, send an inquiry to the known/predefined phone number, and then get the legitimate user’s sensitive information (such as their bank balance). One might argue that a handset must be registered first, but that should not be considered a protection layer because sending 20,000 SMS messages, where 10,000 are unregistered, does not affect a focused attacker much. Furthermore, any information that is given to the user, whether it is an account balance or a trusted/unique URL, based on the caller ID value should be not considered trusted. For example, some organizations will give a unique URL to every user that must be used with a valid PIN to access a WAP/Mobile HTML site. Unlike with SMS, the PIN is required to enter the mobile site; however, the unique URL can be obtained over SMS. Similar to the “balance” request, an attacker can send a request via SMS for the unique URL for any victim. Once the attacker has the unique URL by spoofing the caller ID, they can then begin the process of brute-forcing the PIN. Either way, using SMS to identify a user is very difficult and should not be considered the most secure option.
The use of Secure Sockets Layer (SSL) and/or Transport Layer Security (TLS) is a critical aspect of online security. SSL/TLS is used often by web applications to keep sensitive information private over the Internet, bringing confidentiality and integrity to HTTP (via HTTPS). The need for transport security, via SSL/TLS, between a user’s mobile device and its destination is equally important, as a growing number of sensitive online activities take place on the mobile device and not the PC. This section will review the use of encryption in both WAP 1.0 and WAP 2.0.
In the early days of the mobile WAP world (WAP 1.0), TLS was used, but not end to end. WAP 1.0 used a three-tiered architecture, including the WAP mobile device, which in turn used a WAP browser, a WAP gateway (also known as a WAP proxy server), and the web/application server on the Internet. WAP 1.0 mobile devices mostly spoke Wireless Markup Language (WML), which is similar to HTML. The WAP gateway would translate HTML from the web/application server on the Internet to WML for the WAP browser on the mobile device. The use of the WAP gateway was fairly important in the early days because it would encode/decode all the data to/from application servers to fit the data, size, and bandwidth restraints of the mobile devices. In terms of security, the WAP gateway also played an important role. Due to the limited horsepower on mobile devices (including bandwidth, memory, battery, and CPU), full TLS connectivity between the mobile device and the web/application server was not used. Instead, Wireless Transport Layer Security (WTLS) was used between the mobile device and the WAP gateway, and SSL/TLS was used between the WAP gateway and the web/application server (see Figure 4).
Before we go further, we should pause and talk a bit about WTLS. WTLS is similar to TLS and provides transport security between mobile clients and WAP gateways. It is based on TLS, but is used for low-bandwidth data channels that would normally not be able to support a full-blown TLS implementation. Similar to TLS, WTLS provides confidentiality and integrity using standard block ciphers and MACs.
The WAP 1.0/WTLS architecture brought up several concerns for mobile users and security professionals, due to the absence of full end-to-end security. The process of converting communication between WTLS and TLS would occur at the WAP gateway (encrypting/decrypting), making it an entity that performs a man-in-the-middle attack, although legitimately. This meant that sensitive information was left in a plain-text format, either in memory or in cache, or even written to disk, on the WAP gateway itself. Because the WAP gateway is an entity that is owned and managed by an ISP, not by a bank or e-commerce institution, the ISP would have access to plain-text data from any user using their gateway. Although trusting every ISP in the world and their WAP gateways may have looked great on paper, the idea did not float too well with many sending and receiving entities. This scenario—known in some circles as the “WAP gap”—was not an acceptable option to many organizations because the ISP’s WAP gateway could see all the decrypted information to/from the mobile device. Whether it is a hostile ISP or simply bad practice, the idea of sensitive information being decrypted and then reencrypted between two trusted entities did not sit well with many banking institutions and e-commerce vendors.
SSL and WAP 2.0
Due to the security concerns of the WAP gateway (WAP gap) and its legitimate use of a man-in-the-middle attack, full end-to-end security was supported in WAP 2.0. In the WAP 2.0 world, the WAP gateway was no longer required and became an optional device. Full TLS end-to-end encryption is supported between the mobile device and the web/application server, due to HTTP 1/1 support. A WAP gateway could still be used, but for optional supporting purposes such as optimization. Its role became more similar to a standard proxy-type device rather than a required translation device. With the full end-to-end support of TLS between the mobile device and web/application server, WTLS is no longer needed. Figure 5 shows an example of TLS connections in the WAP 2.0 architecture.