The first part of the SMS banking series included an overview of SMS banking, the components involved in SMS banking and the recommended secure network architecture for SMS banking. In this issue we will see some vulnerabilities in the SMS banking environment that an attacker can make use of and mitigation techniques for the same
The first part of the SMS banking series included an overview of SMS banking, the components involved in SMS banking and the recommended secure network architecture for SMS banking. In this issue we will see some vulnerabilities in the SMS banking environment that an attacker can make use of and mitigation techniques for the same. We consider the following architecture discussed in the previous issue:
In our example the mobile banking application (marked E2M in the diagram) accepts the following input from the bulk service provider to show the account balance of a registered user whose cell phone number is say 9820209954.
https://smsbanking.xyzbank.com?<xml version=”1.0”><request><cellno>98202099548</cellno><query>acct balance</query></request>
As seen above, the message contains the request parameters embedded inside XML tags in the query string. On receiving this request, the mobile banking application searches for the user account number corresponding to the mobile number; on finding a match, it sends the following answer as an asynchronous message to the provider. This is a new HTTPS request with the balance.
https://bulkservice.com?<xml version=”1.0”><response><cellno>9867287798</cellno><querydetails>acct balance=10000Rs</querydetails></response>
The bulk service provider application then picks the account balance details of the user and sends it to the subscriber via SMS.
You might now wonder what insecurities could really be there in such a seemingly foolproof design. Very true, Cross site scripting, SQL injection and Buffer overflow attacks may not be possible from a cell phone but there are vulnerable points in the architecture which can be attacked: they are the mobile banking application and the bulk service provider’s server. If an attacker reconstructs any one of the two HTTPS requests (sent from the bulk service provider to the mobile banking application or vice-versa), he will be able to flood the valid user with SMS messages. This may lead to the user believing that someone else is requesting the account details on his behalf. Worse if the application displays the information contained in the second request message (from the mobile banking application to the bulk service provider) after the attacker has successfully created the first request message (from the bulk service provider to the mobile banking application) on the browser itself, he will get to see critical information like the account balance details of a valid user.
In the following sections we will discuss a few vulnerabilities that can be found in a SMS banking application and the fixes for these vulnerabilities.
The application does not perform proper validations on the messages received from the servers (mobile banking application server or bulk service providers server). A malicious user can try to construct the exact message format sent from the bulk service provider to the mobile banking application or vice-versa to see critical user details and send unsolicited messages (with the account details) to the valid user.
The attacker can view critical user information like account details of a valid user that can be used to carry out further attacks. Also it will result in unsolicited SMS to be sent to the user. This can lead to the user believing that someone is requesting his account details on his behalf which in turn will lead him to cast aspersions on the security controls employed by the application.
On entering the link constructed from the error messages, as discussed above, the application displays the account details of the valid user as shown. As seen below, the attacker can see the username, part of the account number and the available balance. This information gathered can then be used to carry out further attacks.
Even if the display on the browser is stopped, still the valid user will receive unsolicited SMS giving his account balance details as the mobile banking application will service this request as a valid request from the bulk service provider’s server.
Note: This attack can also be tried out by sending the exact HTTPS request message from the mobile banking application to the bulk service provider’s application.
The mobile banking application must accept input only from the bulk service provider’s server. Before accepting any request, the mobile banking application must check for the sender’s client side SSL certificate. Hence an attacker impersonating as the SMS service provider and then sending the exact message as input will fail to get authorized and the attacker will not be able to see the valid user account details and also the valid user would not be bombarded with unsolicited SMS. This control must be present on the bulk service providers end too, such that it accepts responses only from the mobile banking application.
Improper Error Handling
The application does not have proper error handling mechanisms in place. An attacker can make use of this flaw by supplying specially crafted messages to the application thereby resulting in the application displaying critical backend information as part of the error message.
An attacker can make use of the critical backend information gathered to launch further attacks on the application.
Access the URL
https://bulkservice.com?<xml version=”1.0”><response</response>. The following error is displayed which shows that the next field expected is cellno.
From the error thrown, it is clear that cellno is one of the column names in the database and that the application expects it as the next XML tag. In this way the remaining tags can be found out and the whole link can be reconstructed.
The application should have strong error handling mechanisms in place. By entering unexpected inputs, backend information should not be disclosed to the malicious user. Error handling must be performed through well thought out schemes and all exceptions that can be possibly generated by the application must be taken care of and handled in the application. Errors generated by the application should provide necessary message to the user, information to developers but absolutely nothing to attackers.