Temenos OFS Field Injection: Revealing a Hidden Financial Attack Vector

A quick search for the error code TAFJERR-1060 confirmed that:

1. The backend system was indeed Temenos
2. The injection point was interacting with OFS
3. The comma had broken OFS structure

Press enter or click to view image in full size

Now aware that I could influence the OFS request, I continued testing additional characters while researching the integration format. After a few hours of analysis, the behavior aligned perfectly with OFS syntax: the injected comma attempted to start a new field but failed to form the complete <FIELD>::=<VALUE> format, producing a parsing error.

Important Constraint: OFS transactions only allow one operation per request, meaning we are locked into the existing operation structure until the injection point. With that in mind, a typical request payload around the injection point looks like:

FUNDS.TRANSFER,<VERSION>/I/PROCESS,<USER>/<PASS>,,<FIELDS>,DEBIT.AMOUNT::=<INJECTION_POINT>,<OTHER_FIELDS>

Next, I enumerated supported fields for FUNDS.TRANSFER and identified several that could directly affect transaction outcome, including:

• TRANSACTION.TYPE : Type of funds transfer transaction (Values: AC — Account Transfer, TT — Telegraphic Transfer, DD — Demand Draft, RT — Real Time Transfer, CH — Cheque)
• DEBIT.ACCT.NO : Account to be debited
• DEBIT.CURRENCY : Currency of the debit account
• DEBIT.AMOUNT : Amount to be debited
• CREDIT.ACCT.NO : Account to be credited (for account transfers)
• CREDIT.CURRENCY : Currency of the credit transaction
• PROCESSING.DATE : Date when transaction should be processed (Format YYYYMMDD)

Testing demonstrated that some fields (such as DEBIT.AMOUNT) enforced positional constraints, but others did not, making exploitation possible.

Scenario 1# Deduct Money from a Victim Account

While experimenting with OFS field injection, I focused on fields that directly influence the internal behavior of a FUNDS.TRANSFER transaction. One of the most impactful was DEBIT.ACCT.NO, which defines the account to be debited during the operation. Normally, this field should be set by the application to the authenticated user’s account, ensuring the initiated transfer deducts funds from the correct source.

However, because user-controlled data was injected directly into the OFS request without sanitization, it was possible to override this field entirely. By injecting additional fields immediately after the position of DEBIT.AMOUNT, the malicious input became part of the final OFS command processed by Temenos. The only requirement was ensuring the injected segment remained syntactically valid by correctly following OFS formatting rules.

For example, injecting:

100,DEBIT.CURRENCY::=EGP,DEBIT.ACCT.NO::=0000000000000789

does three things:

1. Sets a valid currency value (DEBIT.CURRENCY::=EGP) to satisfy field ordering and validation rules.
2. Introduces a new value for DEBIT.ACCT.NO, completely replacing the legitimate account number assigned by the application.
3. Causes the core banking system to debit the victim’s account, while the receiving account (belonging to the attacker) still receives the funds normally.

Temenos processes the transaction as if the victim legitimately initiated it themselves. The transfer completes successfully, and the system reflects a legitimate outgoing transaction from the victim’s account. No validation fails, no anomalies are raised, and from the core banking system’s perspective, the transaction appears fully authorized.

This demonstrates that once the attacker can control the OFS field structure, the integrity of financial operations depends entirely on the application’s ability to properly sanitize and escape input before constructing OFS messages.

The transaction executed successfully, the logs recorded normal activity, and the only forensic evidence resided in the victim’s transaction list, a damaging but detectable outcome. The next scenario, however, removes even that trace.

Scenario 2# Transfers with No Balance Deduction

One field immediately raised suspicion:

PROCESSING.DATE

At first glance, you might expect setting a future processing date to either:

• Delay execution, or
• Hold the required funds until the set date

However, testing showed otherwise.

The transaction completed successfully, crediting the receiving account immediately, while no balance was deducted or held from the sender account at all.

This enabled unlimited transfers far beyond available balance. To validate, I:

• Set the processing date to a future value
• Waited for the actual date
• Confirmed no deduction ever occurred

Further consultation confirmed that no holds or pending entries existed in the system. The transactions appeared legitimate but left almost no trace, enabling silent fund theft.

Pushing the value further eventually reached:

20600831

Beyond which the system returned validation errors due to missing holiday calendar configuration:

100,DEBIT.CURRENCY::=EGP,PROCESSING.DATE::=20600831

The Solution

The fix is straightforward:

Sanitize user-controlled input before inserting it into OFS requests.

Prevent characters such as:

, ", /, //, _, :, =

from being interpreted as OFS syntax components unless intentionally introduced.

This case shows how missing basic input handling in critical financial systems can lead to high-impact business compromise and reminds us that even a single error message can reveal valuable insight if properly investigated.

Mnemonics: A Remaining Risk

Even after sanitization, another Temenos feature Mnemonics may introduce secondary risk. Mnemonics allow assigning aliases to accounts, such as using OMAR instead of 0000000000000123. Without strict validation, this can be abused in some contexts and should be accepted only where business requirements justify it. Backend controls should ensure Mnemonics cannot bypass account-format expectations in sensitive operations.

Break it right, secure it tight 😉