Key points:

• Attackers are ingeniously stitching together diverse tactics, crafting a spectrum of threats that don’t fit into a single category and require multi-faceted counterstrategies.
• Deceptive maneuvers, exemplified by social engineering and bogus contributions, have become a staple in attackers’ arsenals, underscoring the weaponization of trust and authenticity in digital spaces.
• Abandoned digital assets are not relics of the past; they are ticking time bombs and attackers have been increasingly taking advantage of them, transforming them into trojan horses within the open-source ecosystems.
• The threat landscape’s relentless evolution emphasizes the imperative of predictive threat modeling, a strategy that combines foresight with robust defense mechanisms to anticipate and neutralize emergent attack methods.

Social media as a launchpad

Adversaries have been increasingly leveraging social media platforms for networking and professional collaboration to create fake profiles or impersonate legitimate entities and capitalize on the inherent trust within social circles to push malicious packages. The phenomenon signifies a broader tactical shift: the weaponization of trust and familiarity becomes a gateway to compromise. 

A recent example includes the nation-state actor, Lazarus, which conducted a highly targeted campaign on the blockchain and cryptocurrency sectors. They used social engineering and false developer reputations to trick victims into using malicious open-source packages.

Attackers are also using platforms like GitHub to deceive their targets with fake Proof of Concepts (PoCs). These tactics involve reusing older PoC codes to craft misleading scripts for recently disclosed vulnerabilities. Unsuspecting security researchers or cybercriminals seeking legitimate vulnerability demonstrations can easily be misled by these fraudulent PoCs.

Multi-package tactics and selective droppers

The growing sophistication of attackers is also demonstrated through the orchestrated use of multiple packages. By splitting malicious actions across multiple packages, the attackers make each package (in isolation) appear less suspicious. The malicious intent then becomes obscured, and is only truly unveiled when all the pieces, or packages, are interlinked and operational. This strategy artfully evades detection, as an investigator examining a single package may overlook or underestimate its true potential for harm.

 The Lazarus group implemented this tactic in their recent assault campaign. In this instance, the malicious packages were designed to function in pairs and in a sequential manner. Each pair of malicious packages was published from a separate NPM user account.

The targeted user would receive these NPM packages set to execute upon installation. Once activated, the first package would create a directory, fetch updates from a remote server, and store them in a file. The second package would read a token from this file, send a request to a specific URL with this token, write the response to another file, and then execute that file as a Node.js script.

Further deepening the complexity of such attacks are “selective droppers”. These are advanced mechanisms which, upon execution, determine the environment they’re in and decide whether to deploy their malicious payload or remain dormant. By doing so, they can avoid environments that might be sandboxes or traps set up by security researchers, ensuring their actions are reserved for genuine targets. This selective approach not only evades common detection strategies, but also exemplifies the extent to which cyber adversaries are refining their tools to outwit and outmaneuver modern defenses.

The masquerade of commits: doppelgänger contributors

Equally unsettling is the rise of commit fraud, where cybercriminals have been sighted for the first time this year, mimicking authentic and highly reputable contributors. By pushing fake commits, on behalf of these contributors they create an aura of legitimacy while embedding their malicious code. These maneuvers are particularly insidious as they target the foundational trust and collaborative spirit within open-source communities. It becomes imperative for project maintainers to employ rigorous validation protocols, ensuring contributors are who they claim to be, and all commits undergo meticulous scrutiny.

You can learn here more about how exactly attackers were able to recently spoof commits appearing to be from GitHub’s Dependabot:

Surprise: When Dependabot Contributes Malicious Code

Digital grave robbing

One of the more alarming methods attackers are employing is the takeover of neglected digital assets. From forsaken RubyGem packages to abandoned AWS buckets, what is discarded is not always forgotten. These opportunistic attackers revive these assets, inject malicious code and transformthem into unsuspecting delivery mechanisms for malware. This strategic revival of digital assets underscores the importance of robust digital asset lifecycle management and continuous inventorying and monitoring.

Hybrid threats

Attackers continually strive for obscurity, increasingly intertwining tactics to make detecting malicious packages more challenging. A prime example is the recent supply chain attack targeting Telegram, AWS, and Alibaba Cloud users. In this incident, the attackers exploited a simple human error – misspelled package names and reliance on star ratings – for deceit (Typosquatting combined with Starjacking). They further complicated detection by camouflaging malicious code within the package functions instead of common auto-install scripts. This method bypasses traditional detection mechanisms, making the packages more challenging to detect. By incorporating their malicious code into these functions, routine actions unexpectedly trigger harmful outcomes. This manipulation not only breaches trust but also weaponizes routine. To understand this tactic, we must dissect regular operations, which calls for advanced defensive strategies. These strategies should combine automated tools with human oversight to detect anomalies and counter these hybrid threats.

Combination of Starjacking, Typosquatting, and hiding code within routine function

Beyond the horizon: forecasting threat evolution

The realm of cyber threats is not stagnant. It is continuously morphing and forging new paths of disruption. Current strategies can quickly become outdated, making it vital for defenders to act as both strategists and visionaries. This dual role demands a proactive approach, where possible attack paths are anticipated and neutralized before they occur. Just like in chess where the players need to anticipate moves several steps ahead to avoid being checkmated.

Conclusion

Although the number of supply chain attacks has been on the rise, what is more concerning is the level of sophistication of these attacks. The landscape of cyber threats, especially within software supply chains, continues to morph, mirroring the dark creativity of adversaries. Threat actors have become architects of confusion and deception, exploiting trust, familiarity, and the slightest oversight to infiltrate systems and cause damage.

The fight against these threats sprawls beyond the confines of our infrastructural perimeters, encompassing every part of our digital interactions – from the smartphones in our pockets to vast global networks. 

Investing in collaborative forecasting, strengthening intelligence sharing, and maintaining a fluid defensive posture are the keystones upon which the cybersecurity community must build.

Let’s keep working together to keep the cyber-ecosystem safe.

Learn how Checkmarx and AWS have partnered to help your financial services firm adapt to the evolving landscape

The way we bank has changed beyond recognition. Where transactions once took place in person within the walls of impressive buildings, we now see mobile and online banking on the rise. Anywhere, anytime, palm-of-your-hand banking is the norm, and our expectations are shaped by the seamless, personalized app experiences that have become the default in the digital universe. At the same time, the global acceleration of digital banking licenses has created a new competitive landscape populated by fast-moving market entrants and born-in-the-cloud providers.

One thing that hasn’t changed, though, is the position of trust at the cornerstone of the banking system. Indeed, in today’s volatile economic and cybersecurity environment, building brand trust is more important than ever. Whether you are a legacy brand or a new market entrant, any lack of trust compromises your ability to succeed.

So financial services firms face a continuing challenge: how to innovate at the speed required without compromising customer safety and system security? Most are turning to the cloud for answers. Its flexibility and scalability are making it central to financial service organizations’ efforts to embrace new trends and deliver innovative services at pace.

AWS has some intriguing solutions to meet the challenge. The cloud leader provides a full suite of services to help banks achieve the agility to thrive in the digital age, while certified partners such as Checkmarx ensure the security of the applications and services banks develop.

Recently, the team at AWS identified seven key trends that are impacting the financial services industry. Here we take a deep dive into three areas where AppSec is highly relevant and explore what they mean for the sector.

Trend 1: Customer experience — speed and security must be dual priorities

Today, the economic power is passing to a digital-native generation with little loyalty to legacy banking brands and great expectations of how personal and business financial services should perform. This means customer experience is the modern commercial battleground. Banking must be hyper-personalized and service-led. Increasingly, banking is integrated into consumers’ day-to-day journeys through embedded financial services within trusted brands such as Starbucks and Uber.

Banks are leaning heavily on AI and machine learning to predict customer needs through analysis of internal and external datasets, while the omnichannel drive continues through solutions such as authentication based on voice recognition, real-time sentiment analysis of customer service calls, chatbot support, and automated self-service options.

AWS supports these initiatives and many more through cloud-powered big data analysis that allows banks to leverage AI and machine learning on a massive scale. It also, in its own words, “helps compress time to innovation and, ultimately, time to value, by facilitating rapid development, testing, and deployment to produce new ideas and customer propositions.”  

AWS allows banks to accelerate innovation through its cloud-native application development services, but they also need to ensure the code they create is secure and resilient. Achieving application security assurance without putting a brake on delivery speed is crucial. However, a recent Checkmarx survey of banking and insurance CISOs found that 84% of respondents undergoing digital transformation and implementing a cloud-native strategy were concerned about secure application development and deployment.

As an AWS accredited partner, Checkmarx understands that security must work at the speed of DevOps. The Checkmarx One Application Security Platform is designed for the cloud development generation and delivered from the cloud, bringing integrated one-click AppSec testing that allows financial services companies to deploy more secure code — fast.

Trend 2: Ecosystem-based banking and banking-as-a-service — APIs take center stage

The open banking era is unlocking the doors to greater innovation and collaboration. Providers can now seize new opportunities to develop products that blur the boundaries between different types of financial services. They are establishing solutions that offer their banking services, including fully managed banking propositions, to third parties securely via microservices and a common platform.

AWS identifies two key approaches to this trend. The “marketplace” approach sees banks providing “value-added and contextualized services to their customers such as ERP integrations or personal finance management.” The aim is to deepen the relationship with individual and business customers beyond basic service provision.

The “banking-as-a-service” approach sees banks offering a range of services — from standalone specific regulatory-driven services like Know Your Customer’s Customer (KYCC) to fully managed offerings that let any organization set up a branded banking service.

Center-stage in both approaches are the bank’s APIs, designed to allow banking products and services to be distributed to customers and third parties. Modernizing API architecture in the cloud accelerates the development and testing of APIs, making them easier to integrate as well as providing scalability.

Checkmarx API security offers banks and their customers and partners a crucial service that helps discover, control, and mitigate API security risk. It offers complete visibility into your API inventory and identifies vulnerabilities and misconfigurations. Controlling API risk is an essential component of developing financial marketplace ecosystems and banking-as-a-service solutions.

Trend 3: Cyber event recovery — reducing the attack surface and responding to regulatory requirements

Given its nature, it is not surprising that the financial services sector faces more cyberattacks than any other. On top of these external incursions comes the disruption of digital transformation, which can also create vulnerabilities including third-party and supply chain risk.

Banks are investing in a range of measures designed to manage and mitigate risk and accelerate recovery from any attack. Reducing the attack surface and minimizing vulnerabilities is an essential activity if the sector is to safeguard its reputation and maintain customer trust. Additionally, the growing library of regulations designed to ensure banks are meeting their security obligations means they need to adopt solutions that support compliance.

AWS offers a wealth of solutions to ensure client data is protected and banks can recover quickly from attacks. These include Amazon Simple Storage Service (Amazon S3), key management services, software-defined firewalls that facilitate network isolation, and geographic sovereignty solutions that meet compliance requirements.

These and many other offerings take care of Amazon’s part of the shared security bargain, however, banks are also responsible for securing the workloads they deploy in AWS. This is where Checkmarx steps in, providing comprehensive AppSec solutions that integrate seamlessly with AWS SDLC tools to secure the entire process. Checkmarx addresses all types of application risk, from custom code errors to open source component vulnerabilities, API risks, and infrastructure as code misconfigurations.

These are dynamic times for financial services firms, and AWS with Checkmarx are helping them capitalize on opportunities while defending against threats — both malicious and competitive.

Interested in learning more?

We’re exploring these trends in detail in our webinar on May 4, 2023, where AWS and Checkmarx will explain how you can turn AppSec into a competitive advantage as you continue your cloud transformation journey.

REGISTER FOR THE WEBINAR

Stay Ahead of Supply Chain Attacks: Secure Your Banking Sector Software

At the time Solidity was proposed, it had significant differences to other languages also targeting the EVM (e.g., Serpent, LLL, Viper, and Mutan) such as mappings, structs, inheritance, and even a natural language specification NatSpec.
Like other programming languages targeting a Virtual Machine (VM), Solidity is compiled into bytecode using a compiler: solc.

Smart Contracts can be seen as a computer protocol intended to complete some task according to the contract rules. In the cryptocurrencies context, smart contracts enforce transactions’ traceability and irreversibility, avoiding the need of a third-party regulator like banks. This concept was suggested by Nick Szabo back in 1994.

This article is an introduction to Solidity from a security standpoint, created by the Checkmarx Security Research Team.
As more and more people/organizations look to blockchain as a promising technology, and being willing to build on top of it, it is mandatory to apply software development best practices such as code review, testing, and auditing while creating smart contracts. These practices become even more critical as smart contracts execution happens in public with source code generally available.

It is hard to ensure that software can’t be used in a way that was not anticipated, so it is essential to be aware of the most common issues as well as the exploitability of the environment where the smart contract runs on. An exploit may not target the smart contract itself, but the compiler or the virtual machine (e.g., EVM) instead.
We cover that in the next sections, providing a Proof-of-Concept that demonstrates the discussed topics.

Preamble

In the context of Ethereum (abbreviated Eth), Smart Contracts are scripts that can handle money. These contracts are enforced and certified by Miners (multiple computers) who are responsible for adding a transaction (execution of a Smart Contract or payment of cryptocurrency) to a public ledger (a block). Multiple blocks are called blockchain.
Miners spend “Gas” to do their work (e.g., publish a smart contract, run a smart contract function, or transfer money between accounts). This “Gas” is paid using Eth.

Common Issues

Privacy

In Solidity, private may be far from what you may expect, mainly if you’re used to Object-Oriented Programming using languages like Java.
A private variable doesn’t mean that someone can’t read its content, it just means that it can be accessed only from within the contract. You should remember that the blockchain is stored on many computers, making it possible for others to see what’s stored in such “private” variables.
Note that private functions are not inherited by other contracts. To enable private functions inheritance, Solidity offers the internal keyword.

pure/view functions

Preventing functions from reading the state at the level of the EVM is not possible, but it is possible to prevent them from writing to the state ( i.e., view can be enforced at the EVM level, while pure cannot).
The compiler started enforcing that pure is not reading the state in version 0.4.17.
Source

Reentrancy

Reentrancy is a well-known computing concept, and also the cause of a $70M hack back in June 2016 called the DAO (Decentralized Autonomous Organization) Attack. David Siegel authored “Understanding The DAO Hack for Journalists” a complete events timeline and comprehensive explanation of what happened.
“In computing, a computer program or subroutine is called reentrant if it can be interrupted in the middle of its execution and then safely be called again (“re-entered”) before its previous invocations complete execution.” (Wikipedia).
By using a common computing pattern, it was possible to exploit a Smart Contract. It is still possible. The call() function is the heart of this attack, and it is worth noting that it:

• is used to invoke a function in the same contract (or of another contract) to transfer data or Ethereum;
• does not throw, it just returns true/false;
• triggers the execution of code and spends all the available Gas for this purpose; there’s no Gas limit unless we specify one;

The following warning message was taken from Solidity’s documentation:
“Any interaction with another contract imposes a potential danger, especially if the source code of the contract is not known in advance. The current contract hands over control to the called contract and that may potentially do just about anything. Even if the called contract inherits from a known parent contract, the inheriting contract is only required to have a correct interface. The implementation of the contract, however, can be completely arbitrary and thus, pose a danger. In addition, be prepared in case it calls into other contracts of your system or even back into the calling contract before the first call returns. This means that the called contract can change state variables of the calling contract via its functions. Write your functions in a way that, for example, calls to external functions happen after any changes to state variables in your contract so your contract is not vulnerable to a reentrancy exploit.”
The highlighted part in bold text above is exactly how a Smart Contract can be exploited due to Reentrancy. In the Proof-of-Concept section below and in the accompanying video, there’s a ready to run example. To avoid this attack:

• “be prepared” – any function running external code is a threat;
• These functions:
  <address>.transfer(uint256 amount)/ <address>.send(uint256 amount) return (bool)
  are safe against Reentrancy as they currently have a limit of 2300 Gas;
• if you cannot avoid using call(), update the internal state before making an external call.

Overflow

Solidity data types are cumbersome because of the 256 bits Virtual Machine (EVM). The language does not offer a floating point representation and data types shorter than 32 bytes are packed together into the same 32 bytes slot. The literal 0 type-infers to byte, not an int as we might expect.
Being limited to 256 bits, overflow and underflow are something we may expect. It can happen with a uint8 whose max value is 255 (2ˆ8-1 or 11111111)

OverflowUint8.sol source code or with a uint256 whose max value is 1.157920892×10 (2ˆ256-1)

OverflowUint256.sol source code
Although uint256 is suggested to be (more) secure as it is unlikely to overflow, it has the same problem than any other data type. The batchOverflow bu (CVE-2018–10299) is a great example of a uint256 overflow.

Proof-of-Concept

Consider the following Bank Smart Contract which keeps tracking of balances for addresses that put ether on it.

A careful look at the withdraw() function reveals the reentrancy pattern highlighted in the above correspondent Common Issues > Reentrancy section external call before internal state update.
Now we need a malicious crafted Smart Contract to exploit the Bank one: Thief

Let’s rehearse the robbery using a Solidity development environment. To run it we’ll just need a docker enabled environment.
Clone the solidity-ddenv project and move inside the solidity-ddenv folder
$ git clone https://github.com/Checkmarx/solidity-ddenv && cd solidity-ddenv
Let’s start the development environment
$ ./ddenv
Creating network “solidityddenv_default” with the default driver
Creating ganache … done
Creating truffle … done
If ddenv started correctly you’re expected to be inside workspace folder (you can check it running pwd).
Let’s move into reentrancy directory where the Bank and Thief Smart Contracts are located
$ cd reentrancy
Now, it’s time to compile the source code
$ ddenv truffle compile
Starting ganache … done
Compiling ./contracts/Bank.sol…
Compiling ./contracts/Migrations.sol…
Compiling ./contracts/Thief.sol… Writing artifacts to ./build/contracts
and deploy the Smart Contracts to our development network:

We are now ready to perpetrate the attack. Let’s spawn a console to our development network so that we can issue a few commands
$ ddenv truffle console –network development
Starting ganache … done
truffle(development)>
truffle(development) > is the prompt. If you want to run the attack yourself, just copy the commands next to the prompt from the scripts below and paste them into the console prompt you have launched before.
Now, let’s


Discovering vulnerabilities like the one mentioned above is why the Checkmarx Security Research team performs investigations. This type of research activity is part of their ongoing efforts to drive the necessary changes in software security practices among organizations worldwide.