Attack-driven Testing of Payment Management Systems for Credit Cards

As credit cards being a status symbol are being used by almost everyone, managing their
payments has become an increasingly complex area. Credit card payment management system is
the most common banking application, so the need for having a foolproof secure system is of
prime importance. Software testing engineers are building comprehensive threat profiles and test
plans by proactively putting themselves in the shoes of smart attackers.
The objective of deploying such an attack-driven testing is that security holes in these sensitive
applications can be plugged to the best possible extent before an attacker can find them. Of
course there is no end to the imagination of evil minds, yet the testers have to stay constantly
alert on the new potholes.

An overview of credit card payment management systems:
Credit card payment management systems are used by banks to track the payments and follow up
on past due payments. These applications automate a lot of the work in managing card payments
and reduce the manual interventions required for ensuring payments.
There are many ways the bank receives payment for a credit card:

1) Cheques deposited by customers at ATMs and bank branches;
2) Online transfers from Internet banks;
3) Cash payments at the counter at the bank branches;
Where the funds are received as cheques or cash, data-entry operators enter the details to the
credit card payments application. Where online fund transfers are used, messages are exchanged
electronically between the receiving system and the credit card payment system.
The credit card payment management application keeps track of all the payments of the
customers monthly payments, premiums, late fees, interest, etc. It calculates the monthly
charges, generates the credit card statements to be mailed to customers, and sends instructions
for scheduling the dispatch. This is the application that calculates the minimum amount to be
paid in the month and the due dates.
These days payment management applications handle hundreds of different credit card products
for the bank - each having diversified facilities and charges. The monthly credit card statement
should reflect these accurately. Banks regularly create new products to serve new market
requirements, and the payment application has to be flexible enough to keep pace with these
innovations.
The application also has important monitoring functions like - when a customer has defaulted on
payments repeatedly, it can alert the bank to the event. Different types of alerts can be configured
to detect high-risk customers or abnormal behavior.
Administrative users have the privilege to maintain master records for products and create new
users. Data-entry operators have privileges to add new transactions. The help desk can query the
application for the status and details of payments. External applications interface with the
application to provide details of online payments.
The newer-generation credit card payment management systems are generally web-based. Web
services interfaces enable these applications to receive payment details from other systems.
Creation of Threat profiles:
Threat profiles are also of two types: like generic profiles, and the specific threat profiles. The
easiest method to visualize the threats to the security of the application is the combination of the
generic threats and the other threats that are more specifically applicable to the credit card
payment management application.
A) Generic threats profile:
1) The attacker violates the dual approval or maker-checker system.
2) The attacker violates the data integrity in the software application.
3) The attacker bypasses the system used for authentication.
4) The attacker mischievously captures the passwords of some other users.
5) The attacker shuts down the software application.
6) The attacker hijacks the working session of some other user.
7) The local attacker mischievously captures sensitive data out of the users PC.
8) The attacker takes full or partial access of the server machine.
9) The attacker bypasses the audit trails.
B) Threat profiles applicable to credit card management system:
1) A data-entry operator is able to approve a payment without actually being made.
2) The attacker is able to change the due date of payment for a credit card.
3) The attacker is able to change the amount of transaction made on the payment from a users
credit card.
4) The attacker is able to manipulate the credit card service charges & premiums of the users.
5) The attacker is able to manipulate the interest rates on different types of credit cards like
platinum, gold & silver etc.
6) The attacker is able to modify the list of defaulters of credit cards.
7) The attacker is able to prevent the passing of informing about overdue payments to the
customer.
8) A data-entry operator is able to steal the PIN numbers or CVV numbers from the database.
9) A data-entry operator is able to see the statements & other confidential reports related to the
credit card.
10) The attacker is able to deactivate the entries without due authorization.
11) The attacker is able to change the schedule of statements being dispatched to the customer.
Check points in the test plan:
Intelligent software testing engineer following the approach of attack-driven testing uses
following checkpoints in his/her test plan.
1) Can a data-entry operator approve a payment from the credit card without actually
being made?
# Test if we are able to add a false credit card transaction using some parameter manipulation.
2) Can an attacker change the due date of a credit card payment?
# Test if we are able to change the payments due dates with the help of SQL injection.
# Test if we are able to change the payments due dates with the help of parameter manipulation.
3) Can an attacker change the amount of a transaction on a users credit card payment?
# Test if we are able to change the amount parameters with the help of parameter manipulation.
# Test if we can bypass the validations done at the browser.
# Test if we can clear the payments of credit card with the help of SQL injection.
4) Can an attacker manipulate the credit card premiums & service charges of users?
# Test if we can modify the rate of interest charged with the help of parameter manipulation.
# Test if we can modify the premiums of the users with the help of SQL injection.
5) Can an attacker manipulate the interest rates on regular, silver, gold and platinum
credit cards?
# Test if we can modify the credit card with the help of parameter manipulation.
# Test if we can modify the cards interest rate by escalation of privilege with the help of
parameter manipulation.
6) Can an attacker modify the list of credit card defaulters?
# Test if we can edit our list of defaulters or enhance the privileges with the help of SQL
injection.
# Test if we can delete the name of the use from the defaulter list with the help of parameter
manipulation.
# Test if we can access the privileged data without actually logging to the software application.
7) Can an attacker prevent the application from informing the customer about pending or
overdue payments?
# Test if we can switch off some other persons informing using e-mail features by enhancing
privileges with the help of parameter manipulation.
# Test if we can modify the list of outstanding payments with the help of parameter
manipulation.
# Test if we can trick the user into turning off information by e-mail with the help of CSRF
attack.
8) Can a data-entry operator steal the credit card PINs and CVV numbers from the main
database?
# Test if we can modify the SQL queries of database with the help of SQL injection.
# Test if we can transmit the credit card information in a plain text through wire.
# Test if we can capture the information on credit card by using the refresh feature of the
browser, despite logging out by the user.
# Test if we can directly exploit the known vulnerabilities of the database.
9) Can a data-entry operator view the credit card statements & other confidential reports?
# Test if we can modify the requests to view the confidential reports with the help of parameter
manipulation.
# Test if we can see the sensitive reports in the cache/history of the browser.
# Test if we can access the sensitive reports without actually logging to the software application.
10) Can an attacker deactivate the entries of others without authorization?
# Test if we can deactivate credit card entries of some other users with the help of parameter
manipulation.
11) Can an attacker change the schedule of credit card statements being sent to the
customer?
# Test if we can put off the subscription of some other user with the help of parameter
manipulation.
# Test if a user can change the preferences of other users with the help of SQL injection.
Conclusion:
1) Although attack-driven testing is an excellent proactive approach of security testing, yet there
remains a drawback of false sense of security.
2) Comprehensive checklists of attacks as described above must be kept up-to-date with new
experiences. Such checklists are very valuable both to analysts defining requirements and to the
software testing engineers.
3) All said and done, it remains a cat-and-mouse race between the attackers & the testers;
wherein the evil minds usually dominate.