Aujas US

An IDG Ventures Company

Mitigating Security Risks in USSD-Based Mobile Payment Applications

Security breaches are inevitable as mobile usage grows.

The number of mobile users is rapidly growing and expected to cross 3 billion in next 3 years, according to Gartner. Mobile payments and  financial services are going to be among the hottest mobile technology applications. Various communication channels – including SMS, Unstructured Supplementary Service Data (USSD) and IP-based communications – have security vulnerabilities.  This will increasingly cause major security concerns among banks, telecom companies and service providers.

Critical threats such as fraudulent transactions, request/response manipulations, and insecure message communications are directly triggering revenue loss for mobile payment service providers. Sensitive information disclosure due to weak cryptographic implementation, improper account management, and modification of sensitive information may also cause security breaches and loss of sensitive data in USSD-based mobile payment applications.

Experts believe that more security breaches will be inevitable as mobile usage grows. Deploying secure, reliable and robust products is a challenging task since there are multiple channels involved to provide each service. Proper security controls must be an intrinsic part of mobile phones and mobile applications to avoid major business impacts including:

  • Fraudulent transactions (Revenue Loss) through mobile applications
  • Confidentiality (Users sensitive data- credit/debit card data, PIN , user credentials)
  • Revenue loss through communications services misuse
  • Brand value degradation through SIM card cloning and related attacks
  • Misuse of enterprise data through personal handheld devices
  • Fraudulent transactions through USSD and DSTK (Dynamic SIM Toolkit) applications

Unstructured Supplementary Service Data (USSD)

The USSD communication protocol is widely used to provide mobile communication services, location-based services, mapping services, recharge/booking services, and mobile payment and banking services. USSD is preferred over the SMS communication channel. In USSD, direct communication between the sender and recipient is established, which promotes faster data transmission. USSD communication is session-oriented and it is easily implementable while being more user-friendly. The USSD application is connected as interface between the customer’s telecom provider and his bank account. The customer can transact through handheld devices as well as in web-based applications (USSD in IP mode).

Top 5 Threats

Understanding the top 5 security threats for USSD-based apps can help you avoid major business impact

USSD Commands Request/Response Tampering – A malicious user can tamper with USSD command requests and responses through hardware and software interceptors leading to fraudulent transactions. Weak encrypted request and response messages are prime concerns in such threat vectors.

USSD Request/Response Message Replay Attacks – When a phone is lost, an adversary may perform fraudulent transactions through an installed USSD application in absence of authenticating USSD request originator (e.g., by MSISDN, IMEI, PIN and unique Message Tracking ID).

USSD Application Prepaid Roaming Access Test – An adversary may cause direct revenue loss for service providers by using roaming access parameters manipulation and getting unauthorized access to USSD application prepaid roaming services.

Verify Strong Cryptographic Implementation – Weak cryptography implementation for critical data (customer number, card numbers, PIN, beneficiary details – account numbers, balance summary) can be tampered with, leading to fraudulent transactions.

Improper Data Validation (USSD IP Mode Applications) – Improper data validation in USSD IP mode application can lead to SQL injection, cross site scripting attacks. An adversary may purposely insert specifically crafted scripts in user input and may try to use the same to perform malicious actions at the database or at another user’s active session.

Best Practices to Secure USSD-Based Mobile Payment Applications

A systematic approach to assessing and remediating vulnerabilities in mobile applications is critical to ensuring secure payment transactions. The following practices can be helpful:

  1. Detailed and proactive security assessment helps the client ensure secure financial transactions through mobile payment client applications
  2. Mobile client application  and mobile validation layers security are enhanced through a proactive approach during entire SDLC
  3. Detailed analysis of the  security gaps against the security best practices benchmarks
  4. Threat modeling activity using the STRIDE/DREAD approach helps in identifying the application’s vulnerabilities
  5. Mapping identified vulnerabilities to threats brings about a clear understanding of security issues in the application and how they may be exploited
  6. Mapping vulnerabilities to flaws at the architecture and design levels helps prepare a comprehensive remediation plan identifies vulnerabilities in financial transactions, application residing on mobile device and sensitive data transmission over wireless network which automated tools may not detect.

Aujas can help your company manage mobile application risks. Contact Karl Kispert, our Vice President of Sales, to learn more. He can be reached at karl.kispert@aujas.com or 201.633.4745.

Advertisements

May 31, 2011 Posted by | Cyber Crime, IT security, Mobile device security, Secure code development, Secure Development Lifecycle, USSD-based mobile applications | , , | 1 Comment

Mobile Security with J2ME

J2MEWith the large number of financial applications that are available for Java-enabled devices, security is of paramount importance. Java 2 Micro-Edition Connected Limited Device Configuration (J2ME CLDC) is the platform of choice when it comes to running mobile applications on resource constrained devices (cell phones, set-top boxes, etc.). The large deployment of this platform makes it a target for security attacks. The intent of this article is to provide some insight into J2ME security and the common mistakes when developing such applications.

J2ME has fewer features than Java and has a smaller and efficient Java engine designed for small devices.  We could divide the security of J2ME into three categories:

  • Compile/Runtime Security
  • Database
  • User awareness

Compile/Runtime Security. Java compiler and runtime environment through the provision of non-customizable classloaders, pre-verified midlets, protection domain policy and limited/no access to native/reflection API ensures the safety of the mobile devices.  

One of the key improvements over the few years in MIDP is to allow only the trusted application to call the protected API. All trusted API’s would be signed. The trusted store in the mobile phone is usually populated with certificates of manufacturer’s choice and not all known CA’s root certificates are part of the store. The J2ME permission class cannot be inherited to customize the need. Also the permissions are not really atomic to allow finer control. Once permission is obtained by the application from the user the application is allowed to use the resource however necessary.  

Database Security. One of the most ignored parts of the J2ME is the RMS database. The database is a simple byte-level file that stores the contents on the local phone. The security of this file is left to the manufacturers and the application developers. Most of the time the application developers are under the belief that RMS database file is safe to use and it’s well protected. This is not the case. A simple example would be to install the application on a memory card and later on mount the memory card in a computer. You could see almost all the files including the RMS file. Application developers need to realize that nothing is as secure as or more secure than their application. Application-level encryption is a must to protect the local data in the RMS database.

User Awareness. Another factor that J2ME developers should be aware of is the knowledge level of the user base. The mobile phone user is not aware of all the computer-related functionality. The fundamental difference in the user base demands a security at higher level which is less complicated. The current basic security that is implemented in all J2ME application is the certificates.  The expectation that an average user in the market would understand a certificate and invalid application is questionable. As an average phone user, the trust of an application comes from his interaction with it. This interaction should be simple enough for the end user to understand. A better user interface design could help the end user understand the messages that he sees on the screen.  Companies should take special initiatives to spread the security measures.

Bottom line, one should understand that a mobile phone is not better than a laptop; it’s pretty much the same in the hackers’ view.  Beware and be Secure

November 29, 2010 Posted by | IT security, Mobile device security | , , , , , | Leave a comment