Chaining Multiple Vulnerabilities
In this scenario, we are firstly going to view individual vulnerabilities and then chain them to implicate a bigger vulnerablity:
Before we begin, let me give a brief summary of the application. This application is used by organizations to place orders on IVR. Customer calls customer care and requests for products to be purchased, and pays via IVR. This application is divided into 3 parts:
Customer Care Agent Portal:
- Here Agents login and call customers and place order as per customer request. All data such as call time, call id, customer name and number will be shown
Backend dashboard:
- Once agents have customer on call, they navigate to backend dashboard to create a store to select items requested by the customer and place order. Once order is placed, customer can pay through already saved card from customer dashboard or even directly via IVR(during which agent would be on hold, so that they do not know what customer is entering)
Customer dashboard:
- Customer logs into this dashboard and approves for transactions done via saved card. Customer can also view all transactions and invoices along with all products they have purchased.
Now let us go through the list of vulnerabilities I identified, for this i am either a malicious agent, or a malicious customer:
There were multiple vulnerabilities, but these are major ones, and we would see how an attacker would chain these to perform highly malicious intents:
- Customer Care Agent portal
- Backend dashboard
- Customer dashboard
Customer Care Agent Portal:
- Here Agents login and call customers and place order as per customer request. All data such as call time, call id, customer name and number will be shown
Backend dashboard:
- Once agents have customer on call, they navigate to backend dashboard to create a store to select items requested by the customer and place order. Once order is placed, customer can pay through already saved card from customer dashboard or even directly via IVR(during which agent would be on hold, so that they do not know what customer is entering)
Customer dashboard:
- Customer logs into this dashboard and approves for transactions done via saved card. Customer can also view all transactions and invoices along with all products they have purchased.
Now let us go through the list of vulnerabilities I identified, for this i am either a malicious agent, or a malicious customer:
- Agent able to change registered email of customer: Customer entire access is dependent on the email of his account. In such scenarios, no one should be able to change the email of the customer. The front end by default disables the edit feature, but capturing the request using burp leads agent to modify the registered email.
- Agent able to use tokenized cards of every user for any transaction: Lets assume that customer has registered for the first time, they would be using their card to pay via IVR, here bcoz of PCI compliance, the card data is tokenized. But since there is no relationship between tokenized card and user, agent can use that token for any cart transaction of any user. Which means, agent need not even have the customer on call. And create an order, place order later pay it with this tokenized card data. Further, I also found that the there was no rate limiting and monetization limitation. Bcoz of which I was able to increase the cart price and then place entire order with same tokenized card. And reuse the same token multiple times for multiple customers. The impact here is customers card(PCI and PII) data is being used without customer consent, as well as missing a lot of security controls. This impacts financials of customer and resources of the organization, not to forget the reputational damage it would face later.
- Agent able to bypass customer authorization: Lets assume a customer already placed order few months back, so they would have a saved card in the database. Agent, can place order using that and server automatically sends email to customer for approval. Customer has to login to customer dashboard and then approve the transaction, after which the card is cahrged for the corresponding amount. Here, the parameters required for this approval are transaction ID(which agent can get from the order id) and customer id(which agent can get from the same backend dashboard). If an attacker crafts a PUT request with these 2 details and adds a URL parameter such as /?approved_by=customer, all this while being an agent(using session tokens of an agent) the server accepts and processes the payment. Impact here is that the without customer consent or approval, agent can create a cart and place order without even knowing the customer card data. Then approve it and complete entire transaction and the customer is paying the price unknowingly.
- Agent can create order on behalf of another agent: Lets assume there are agent A and Agent B, and their LDAP usernames as A1 and B1. I found a way to create orders on the name of B while being logged in as A. this was possible by changing a simple parameter in the body of the request namely "created_agent" from A1 to B1. This is to be done on first step when creating the cart after the products are selected. From there on, the application assumes that B has created the order. Further diving into this vulnerability, I also identified that the application is not validating the LDAP. So if i put "no_such_ldap_exists_test_123" as created agent, the application is reflecting same even in logs and invoices. So audit trail would be very clean of A. the impact we would see at the end, as to how this could be chained and escalated for a bigger vulnerability.
There were multiple vulnerabilities, but these are major ones, and we would see how an attacker would chain these to perform highly malicious intents:
Lets assume the attacker is a malicious customer care agent. Since the agent can view basic dashboard of agents, they would search for customer data and come across the victim who has already placed order few days back.
From that data, he would first change the email of the customer(Issue #1). Now verification is necessary. Agents can request for email verification from agent dashboard. So, agent would use that, and go ahead and verify their personal email. Note account Id would be same as only registered email is changing not entire account.
Once email is verified, agent would open a store for this person. Go ahead and place an order. Since account is same, agent can use already existing tokenized card and go ahead and use it and place entire order. Since foreign transactions dont required OTP, no user interaction is required. Hence making this more easy for attacker. Once entire transaction is done, agent would get all products delivered to address they would give or email, which is attackers email right now. All this while also exploiting Issue #4. Now, once all this is done, attacker would change the email using Issue #1 back to original email, since email was already verified once in history(customer would do it initially during their first purchase), customer would not even get an email saying they should verify email.
Once customer gets notification of the order, investigation would show audit trail of agent B doing all this, and this is a serious offence of using customer data and PCI data to personal use.
Assume, that for some reason token is not accessible. Agent would use saved card to perform this transaction, but saved card transactions go to customer dashboard. Since, agent already changed email, he would simply request forget password, change password of customer account then login and approve the transaction. Since, OTP is not asked for international transactions, easy peasy job for agent.
Majorly, such vulnerabilities, raised as there was no proper authorization and authentication implemented in the application, both on backend and customer dashboards.
Once customer gets notification of the order, investigation would show audit trail of agent B doing all this, and this is a serious offence of using customer data and PCI data to personal use.
Assume, that for some reason token is not accessible. Agent would use saved card to perform this transaction, but saved card transactions go to customer dashboard. Since, agent already changed email, he would simply request forget password, change password of customer account then login and approve the transaction. Since, OTP is not asked for international transactions, easy peasy job for agent.
Majorly, such vulnerabilities, raised as there was no proper authorization and authentication implemented in the application, both on backend and customer dashboards.
Moral: When ever trying to find vulnerabilities, try to exploit at every level and step within the application, as chaining multiple vulnerabilities could lead to a bigger picture and greater exploitability.
Overall, it was fun exploiting this application, and finding some good vulnerabilities after a long time.
Overall, it was fun exploiting this application, and finding some good vulnerabilities after a long time.