BHIM Breach: Policy Guardrails No Longer Optional
On May 31st, researchers reported a massive breach involving financial and personally-identifiable information (PII) connected to India’s largest payment application, Bharat Interface for Money (BHIM). The application provides mobile banking, payments, and finance services across multiple government entities and platforms such as Unified Payments Interface (UPI) to over 15 million registered users.
With 409 GB of data being exfiltrated and around 7.5 million data records stolen, the BHIM breach represents one of India’s largest cloud breaches. Initial analysis suggests that the exposure period spanned from March to May, going undetected for months. To make matters worse, the data that was compromised consisted of highly sensitive information including the following:
- Aadhaar cards (a biometric ID system linked with a host of services including mobile sim cards, bank accounts, and welfare programs)
- Residence cards
- PAN cards (required to file taxes)
- Personal data such as degree certificates
- PII data such as name, date of birth, gender, age, address, religion, and photos
Given the scale and severity of the breach, Accurics researchers dug in to understand the root cause and possible mitigation measures.
Kill Chain Analysis
The BHIM platform runs on Amazon Web Services (AWS) and hosts a number of sites, API servers, and applications; the services are predominantly delivered via mobile applications. It is using AWS S3 buckets (cloud storage service) to store static PII and financial data. Unfortunately, one such bucket named “csc-bhim” containing sensitive data had multiple misconfigurations:
- It was publicly discoverable (misconfiguration = world listable from anonymous users)
- It was publicly accessible (misconfiguration = world readable)
- It allowed bulk downloads (misconfiguration = allowed to get actions from all principles)
- It did not maintain the integrity of the data (misconfiguration = versioning was not enabled)
- Multi-factor authentication was not enabled (misconfiguration = MFA delete not enabled)
An analysis of the events indicates that the S3 bucket “harvesting” began in March 2020 and the “csc-bhim” bucket was discovered. Some time in April or May, a fake AWS account was created and the sensitive data from that bucket was exfiltrated. Researchers discovered the breach and alerted BHIM; the National Payments Corporation of India (NPCI) has denied the breach so far but data on the dark web seems to confirm the allegations.
Key Learnings: Policy Guardrails from Code to Cloud
Misconfigurations have been the single biggest cause of cloud breaches in the past few years. While tremendous efforts have been made by cloud service providers and organizations to manage this issue, cloud breaches continue to increase in scale and velocity.
Much of this can be attributed to the increasing complexity of cloud applications. A single cloud application uses a number of infrastructure components which may include new technologies such as serverless, containers, and servicemesh. Many of these technologies are provisioned and managed through code (Infrastructure as Code – IaC) which increases agility but also the potential for misconfigurations in the code.
Security must be embedded into the development lifecycle from the moment infrastructure is defined through code and the posture must be maintained throughout the lifecycle. In other words, policy guardrails must be enforced across infrastructure as code to eliminate risk before infrastructure is provisioned. The same policies must be enforced after the infrastructure is provisioned to monitor for any configuration changes that are made directly to the cloud. Most importantly, risky configuration changes should be flagged and reverted back to the secure baseline defined through code, while legitimate configuration changes should prompt the infrastructure as code to be updated and reflect the change. This approach of always ensuring that infrastructure as code remains the single source of truth for security posture is known as “immutable security”.
For organizations using S3 buckets, we recommend that the following policy checks are applied across infrastructure as code (IaC) as well in the cloud (after the infrastructure is deployed):
- Ensure that your s3 buckets are not World readable.
- Ensure that your s3 bucket is not World listable from anonymous users
- Ensure that your s3 buckets are not allowed to get actions from all principles
- Ensure that your s3 buckets are not allowed list actions from all principles
- Ensure that your s3 buckets have versioning enabled
- Ensure that your s3 buckets have MFA delete enabled
- Ensure that your s3 buckets have encryption enabled
It is important to note that while policy guardrails are a good first step towards minimizing risk, violations can be difficult to prioritize and remediate without additional context. The above policy checks must be incorporated into more sophisticated techniques which include modeling threats to identify potential breach paths in the cloud. Read our earlier blog to learn more about Breach Path Prediction.