back to article Fintech platform flaw could have allowed bank transfers, exposed data

Salt Security spotted a vulnerability in a large fintech company's digital platform that would have granted attackers admin access to banking systems in addition to allowing them to transfer funds to their own accounts. If exploited, the flaw would have also exposed both users' personal data and financial transactions. "This …

  1. Duncan Macdonald

    Defensive programming

    Defensive programming (assume the input is incorrect or malicious until proven otherwise) used to be a standard feature of important software. Unfortunately this has fallen by the wayside as the urge to cut software development time down has overtaken the requirement that the software works correctly.

    For any financial application that is responsible for significant amounts of money, common sense would suggest that the code should be built using defensive programming techniques - unfortunately "common sense" is not very common.

    (For a simple example of defensive programming take the following example - paraphrased from the RSX-11M operating system

    Is the function number in range - if not then reject the request

    Does the call have the right number of parameters - if not then reject the request

    Does the program have the right to call the function - if not then reject the request

    Are all the parameters accessible - if not then reject the request

    Only if the above checks were passed would the request be passed on to the requested function which may itself need to carry out further checks on the values of the parameters.

    )

    1. hayzoos

      Re: Defensive programming

      I learned this early on. I even implemented a system where each keystroke was evaluated in some data entry areas with user feedback as to rejection and why not accepted. The complete entry was also evaluated. SQL injection would not pass.

      Each data point needs evaluation. This requires "thinking outside the box" and "thinking inside the box", basically just thinking.

  2. Scott Broukell

    Just asking

    Especially in the case of banking / fintech etc. is there not a very strong case for demanding that such digital infrastructure undergo a comprehensive, independent, testing phase prior to being permitted to go live? In order to bring such potential disasters to light before they can happen!

    Are there not machine learning models and wotnot that could allow such testing to be both rapid and very thorough and free from prying human eyes - if there are any security issues with that?

    (goes back to counting groats with an abacus)

    1. Martin Gregorie

      Re: Just asking

      I'd expect any banking/fintech system which supports direct connections from client systems to require that:

      - their provided interface package or its specification which MUST be used by client systems to connect to the central system

      - a validation package will be used to exercise a client's connection before it is permitted to connect to the central system. This must both confirm that supported transactions and responses perform as expected and demonstrate that the client side can successfully handle and reject invalid and spoofed transactions sent to it.

      - a non-negotiable requirement that the final full functional check before a new client's connection is permitted to go live should be observed by the central system's security team, with anything less than a 100% pass being treated as a fail,

      - this functional check must be repeated whenever the interface specification is updated by the central system or when client software using the interface package is revised.

      Any financial network that doesn't provide such interface specifications and require these functional checks is deficient: using it should be avoided if at all possible.

  3. jvf

    re Defensive programming

    This is how I used to write code. Guess it went out of fashion. My code to validate user input was always longer than the function code. This would be followed by several days of users testing the forms by entering nonsense and alphabet soup into all the input boxes to make sure everything behaved.

  4. Anonymous Coward
    FAIL

    Defensive bean counting

    If we didn't get hit - do nothing.

    If we did get hit and the flaw was fixed by the third party - issue a press release that we responded and hope for the best.

    If we did get hit and the flaw hasn't been fixed - say nothing. do nothing, and hope for the best.

  5. Clausewitz 4.0
    Devil

    Approaches to (in)security

    whitelisting – and runtime protections - easily bypassed by sideloading SIGNED DLL binaries with LoL bins, using valid certificates - $500 USD in the market

    API traffic anomalies - requires the attacker to "train" your AI/ML to accept anomaly as normal business logic. Takes time, but can be done

  6. Anonymous Coward
    Anonymous Coward

    My guess

    *holds envelope to forehead*

    BlackRock Aladdin. Fits the profile to a T.

  7. hayzoos

    Industry Standard Incompetence

    Since the article stated US based company and US banking customers, I do not think BlackRock Aladdin is uniquely qualified to be the culprit, unfortunately. The whole fintech sector is trying to operate out of sight and out of mind to the masses and they are largely succeeding. Security by obscurity is the modus operandi along with security theater for those parts which must be presented for marketing purposes.

    Second or multi-factor authentication if offered let alone enforced is primarily SMS transmitted codes. Anything more is a rare beast indeed. Keep in mind SMS codes should be considered 1.5 factor authentication and even that is being generous. -Industry Standard Incompetence.

    Outsource as much as possible, fintech, firewalling, billpay features, pay peers features, everything except profits is the goal. We all know SLAs will save the day so nothing bad will happen from outsourcing. -Industry Standard Incompetence.

    Outsourced firewalling results in blocking access from VPN's both commercially available and "roll-your-own". Scenario: You are only able access the internet from untrusted networks while on travel. In order to bank online the VPN is your friend, but such access is blocked for "security". -Industry Standard Incompetence. Actually, this extends to many industries thanks to CDNs getting into security services.

    Outsourced billpay, and pay peers features opens the attack surface for customer information. SLAs for security make sure it stays safe though, yeah right. -Industry Standard Incompetence.

    Unfortunately, most fintech industry companies could fit the profile. Unfortunately, a large portion of US banks enable this by the outsourcing trend.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like