Sensitive services have been widely applied in mobile applications such as mobile banking and mobile trading. Mobile banking applications, such as HSBC mobile banking Apps for Android, enable customers to make account management operations through their mobile application. Mobile trading apps, such as Amazon Mobile for iPhone, enable shopping online through a mobile application.

 

In this article, we will walk through an approach to hack a mobile application in order to give highlight on exposed risks.

Our victim application

Let’s assume that we have a mobile application which enables users to purchase products online. The mobile application connects to a web service hosted on a backend server using SOAP (Simple Object Access Protocol). A simplified architecture diagram is shown in figure 1.

Our hacker will be a normal user having credentials to work with the mobile application. He will try to have unauthorized access to make money fraud.

Intercepting Traffic

Before we hack, we will need to understand how the application works in order to identify the attack surface and know the entry points for hacking. Thus, we need to understand the data flow which will allow us to understand how information is sent to and from the server. Moreover, we need to identify the contents and the sequence of the data sent and received while running the mobile application.

To achieve this, we need to intercept the traffic between the mobile application and the server.  We will let the mobile application send traffic through our proxy. Web proxies, such as “Burp” [3],  will be useful here as most mobile apps will use HTTP to communicate with their backend servers.  We have two options here:

• As shown in figure 2, we can configure the HTTP proxy settings in the mobile device to connect  through our proxy. Note that if the traffic is sent over SSL, a warning will appear on the mobile   app which can be ignored.
• Another way is to run the mobile app in an emulator and configure the emulator to connect   to the internet through our proxy.

We will need to go through different screens on the mobile app and keep an eye on our proxy to watch how the traffic is sent between the mobile app and the backend server. It will help us identify the approach used by the application to communicate. Most mobile apps will use either REST (Representational State Transfer) which simply uses HTTP. Others might use SOAP which  sends XML messages over HTTP. Thus, Burp will be so beneficial in intercepting and recreating traffic sent to backend services. For example, we can change the value of ProductID in the SOAP message intercepted as shown in figure 3.

Now, we can use “Burp” to attack the backend service with different types of attacks such as SQL injection and brute force attacks. However, we would like to do something stealthy that cannot be detected by application firewalls. Logic attacks will do it.

Exploiting a Logic Attack

Logic attacks are one of my favorite attacks. In such attack, we abuse the logic of the application to achieve our threat goals. It needs deep understanding of the logic of the application. One of the best papers published in this area is available on [1]. The author elaborated how to shop online for free using business logic flaws in several web applications. Our attack is inspired from this paper.

Figure 4 demonstrates how SOAP messages are sent and received through the victim mobile application in order to execute an order. It starts by sending Product info and ends by receiving the activation code for the purchased product.

Now, let’s try to purchase a product with lower price than its actual price. Assume that Product 1 has lower price than Product 2. Our target is to purchase Product 2 with the low price of Product

1. We will use “Burp” to send SOAP messages to the server with a sequence the server does not expect. Attack scenario will be as follows:

Now, we have succeeded to get activation code for Product 2 although paid for the cheap Product 1. This is due to lack of proper validation on the server side. The server was expecting a Confirm Order SOAP message for Order 1. However, we sent it a Confirm Order SOAP message for Order 2. The server thought that we already paid and gave us activation code for Product 2.

Countermeasures:

Several countermeasures can be applied to overcome the attack discussed in the article.

• Backend service should deal with clients as if they are hackers. Traffic is not always sent from the trusted mobile app. The application should have performed robust server side authorization checks on the requests sent by our interception proxy.

• Logging security events is usually ignored by developers. If logging and alerting was on, the  application administrator would have noticed that we tried to confirm on an order that has not   been checked for cash balance.

• A secure connection should only be established on the mobile application after verifying the  identity of the backend server. For example, if the application uses SSL and does not trust the  certificate supplied by the server, it should block the connection. This would have made using  the proxy more difficult.

• For further guidelines offered by OWASP, please refer to OWASP Top 10 Mobile controls [2].

References:

[1] “How to Shop for Free Online”, http://www.informatics.indiana.edu/xw7/papers/caas-oakland-final.pdf

[2] “OWASP Top 10 Mobile controls”, https://www.owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Controls

[3] “Burp Suite”, http://portswigger.net/burp/

About The Author

Hassan El Hadary,  GCIH, GWAPT I am a Senior Security Engineer at SecureMisr and a Community Instructor at SANS Institute.