The structural vulnerability of USSD
When a user dials `*123#`, their phone communicates with the telecom operator (MTN, Airtel) over the SS7 network. The telecom operator then translates that cellular request into a standard HTTP POST request and sends it over the internet to the bank's designated USSD Gateway API.
The core security problem is a lack of end-to-end encryption. Unlike a mobile banking app that establishes a secure TLS tunnel directly to the bank, the USSD user relies entirely on the telco. If the telco network is compromised, or if the transmission between the telco and the bank is intercepted, the data (including the user's USSD PIN) is exposed in plaintext.
How attackers exploit USSD applications
During penetration tests of Nigerian banking USSD gateways, we do not attack the telecom provider. We attack the bank's API that receives the telco traffic. We consistently find the following high-impact vulnerabilities:
1. MSISDN Spoofing (Identity Theft)
The telco sends the user's phone number (MSISDN) in the HTTP payload to the bank. If the bank's API trusts this number without mutual authentication from the telco gateway, an attacker can simply send an HTTP request directly to the bank's API, changing the `msisdn` field to the CEO's phone number.
2. Session Hijacking
USSD operates in "sessions" maintained by a `session_id`. If the bank generates predictable session IDs (e.g., sequentially incrementing numbers like `1001`, `1002`), an attacker can guess the next session ID, inject themselves into an active transaction, and alter the destination account number before the victim presses "Confirm."
3. Business Logic Bypasses
USSD menus are state machines. Attackers test edge cases: What happens if I send the API a "Step 4: Confirm Transfer" payload when I am currently on "Step 1: Enter Amount"? Poorly written gateways will process the transfer without ever asking for the PIN.
The SIM Swap Epidemic
The most devastating attack vector against USSD is not technical, but social: the SIM Swap. An attacker bribes or tricks a telco agent into transferring a victim's phone number to a blank SIM card controlled by the attacker.
Because the attacker now possesses the victim's phone number, they can dial the bank's USSD code. If the bank relies solely on the phone number and a weak 4-digit PIN (which the attacker might have shoulder-surfed or phished), the attacker can empty the account within minutes.
Testing your SIM Swap Defenses
A robust USSD security architecture must include defensive logic against SIM swapping. During an assessment, we evaluate whether your application:
- Integrates with the telco/NIBSS API to check the "Last SIM Swap Date". If the SIM was swapped in the last 48 hours, USSD access should be heavily restricted.
- Requires a secondary factor (like the last 4 digits of the BVN or ATM card) when resetting a forgotten USSD PIN.
- Enforces strict velocity limits (e.g., freezing the account if the USSD PIN is guessed incorrectly 3 times).
Are you launching a new USSD code or migrating your gateway?
Book a USSD Penetration TestHow to secure your USSD Gateway API
To defend against MSISDN spoofing and API abuse, your engineering team must lock down the ingress point where telco traffic hits your network.
- IP Allowlisting is mandatory: Your USSD API must only accept HTTP POST requests from the officially published IP addresses of the telecom aggregators (e.g., Africa's Talking, InfoBip) or the telcos themselves. Drop all other traffic at the firewall.
- Enforce Mutual TLS (mTLS): IP allowlisting can be bypassed via SSRF. Ensure the telco gateway cryptographically authenticates itself to your API using a client certificate.
- Cryptographic Payload Signatures: Work with your aggregator to ensure that every incoming HTTP request contains an HMAC signature in the headers, proving the payload was not tampered with in transit.
- Aggressive Input Sanitization: USSD inputs are notoriously dirty. Users type letters instead of numbers, or inject SQL characters (`' OR 1=1--`). Ensure your backend strictly type-casts all inputs and uses parameterized database queries to prevent injection attacks.
Do not test in production
USSD penetration testing requires careful coordination. You cannot safely fuzz a production USSD gateway without risking dropped sessions for legitimate customers. A proper assessment requires a dedicated, identical staging environment that accurately mimics the telco's HTTP payload structure.
Frequently asked questions
Why is USSD banking inherently insecure?
Unlike HTTPS traffic on a smartphone, USSD traffic (Unstructured Supplementary Service Data) is transmitted over the cellular signaling network (SS7) without end-to-end encryption. It relies entirely on the telecom operator for security, making it vulnerable to interception and spoofing.
What is MSISDN Spoofing?
MSISDN spoofing occurs when an attacker manipulates the HTTP request sent from the telecom gateway to the bank's USSD API, replacing their own phone number with a victim's phone number. If the bank trusts the phone number implicitly, the attacker gains access to the victim's account.
How does a penetration test evaluate USSD security?
A pentester will not try to hack the telecom network directly. Instead, they will attack the bank's USSD Gateway API. They will attempt to manipulate session IDs to hijack active sessions, fuzz input fields to cause backend SQL injections, and attempt to bypass PIN requirements through business logic flaws.
How do we protect USSD users from SIM swap fraud?
USSD must never rely solely on the phone number for authentication. You must enforce a robust USSD PIN. Additionally, integrate with telecom APIs to query the 'SIM swap date'. If a SIM was swapped within the last 48 hours, automatically disable USSD banking for that number until the user verifies their identity via a secondary channel.
Related reading
Blog: SIM Swap Fraud Defenses · Rate Limiting Payment APIs
Guides: CBN Compliance Guide · Fintech Security Checklist
Services: API Security Testing · Penetration Testing