Victims of a bank data breach are set to receive up to $3,000 each after a settlement was reached in a class action lawsuit.

According to the settlement administration portal, impacted customers at Arizona-based Evolve Bank & Trust who file a claim and provide documentary evidence of losses resulting from the data breach stand to receive up to $3,000.

A flat cash payment of $20 will also be available but claimants can only choose one or the other, not both.

“In addition to selection one of the Cash Payment options, Settlement Class Members may elect one (1) year of monitoring that will provide the following benefits: Credit Monitoring, real-time alerts, and insurance coverage for up to $1,000,000 for identity theft.”

Claims must be filed by October 30th. A final approval hearing of the settlement will be held on November 14th.

The lawsuit against Evolve Bank & Trust was filed in January and alleges that cybercriminals infiltrated the billion-dollar lender’s information systems and gained access to sensitive and confidential information.

In a notice to customers in July of 2024, Evolve Bank said the data breach had occurred between February and May of 2024.

“…it appears the criminals downloaded information from our databases and a file share that included names, Social Security numbers, bank account numbers, and contact information for most of our personal banking customers, as well as customers of our Open Banking partners. We have also learned that personal information relating to our employees was also likely affected.”

Evolve Bank & Trust, which started as First State Bank in 1925, is headquartered in West Memphis, Arizona. It boasts of around $1.6 billion in total assets and has five branches in the US.

Follow us on X, Facebook and Telegram

Don’t Miss a Beat – Subscribe to get email alerts delivered directly to your inbox

Check Price Action

Surf The Daily Hodl Mix

&nbsp

Disclaimer: Opinions expressed at The Daily Hodl are not investment advice. Investors should do their due diligence before making any high-risk investments in Bitcoin, cryptocurrency or digital assets. Please be advised that your transfers and trades are at your own risk, and any losses you may incur are your responsibility. The Daily Hodl does not recommend the buying or selling of any cryptocurrencies or digital assets, nor is The Daily Hodl an investment advisor. Please note that The Daily Hodl participates in affiliate marketing.

Generated Image: Midjourney

This blog post discloses a threat against the Ethereum network that was present from the Merge up until the Dencun hard fork.

Background

Prior to the merge, different message size limits for RPC communication were set to protect clients from denial-of-service (DOS) attacks. These limits, applied to messages received via HTTP endpoints, were carried over to the engine API, which plays a crucial role in connecting Execution and Consensus Layer clients during block production. Due to the engine API’s involvement in block production, it became possible for blocks to be produced that surpassed the RPC size limits of some clients but remained within the acceptable range for others.

If an attacker creates a message that exceeds the size limit of the client with the lowest setting, while still adhering to the gas limit requirements, and then waits for a block to be produced, it could result in a situation where some clients regard the block as valid, while others reject it, issuing a HTTP error code “413: Content Too Large.”

Impact

An attacker that could craft these messages would be able to force the majority of nodes (=geth) to reject blocks that a minority would accept. These blocks would be forked away and the proposer would miss out on rewards.

In the beginning we thought that it was only possible to create these blocks by using builders or a modified version of a client. Geth has a builtin limit of 128KB for transactions, which means that a big transaction like the one under discussion would not end up in the transaction pools of any geth node. It was however possible to still trigger the limit by having a client with a higher limit propose the block and the CL requesting validation of this proposed bigger block.

We proposed a solution in temporarily lowering the RPC limit on all clients to the lowest value (5MB). This would make the block invalid and an attacker would be very limited in the chaos they can cause in the network since the majority of the nodes would reject their blocks.

However on February 7th we discovered that it was possible to create a block that would hit the 5MB limit with a bunch of transactions that are below the 128KB limit and not exceed 30 million gas.

This is a bigger issue because we realized an attacker could create a bunch of high paying transactions and send them to the network. Since he outpays everyone else in the mempool, every node (even geth nodes) would include the attack transactions in their block thus creating a block that would not be accepted by the majority of the network, resulting in a lot of forks (all being deemed valid by the minority nodes) and the chain keeps reorging over and over again.

Later on February 7th, we came to the conclusion that everyone raising their RPC limits would be the safer alternative.

Timeline

• 2024-02-06 13:00: Toni (EF), Pari (EF) and Justin (Besu) try to submit a specificly grinded transaction to the network. The transaction contributes to up to 2.7 MB blocks when snappy compressed.
• 2024-02-06 13:25: Pari receives errors from his local Geth node although the transaction should be valid.
• 2024-02-06 15:14: Justin managed to put the transaction in a block and submitted it through the Besu client.
• 2024-02-06 20:46: Sam (EF) alerts Pari (special thanks to mysticryuujin on X), Toni and Alex about certain Sepolia nodes struggeling.
• 2024-02-06 21:05: Team double checks with Marius from Geth and confirms the bug.
• 2024-02-06 21:10: The gang gets together to debug it
• 2024-02-07 23:40: We decided for all clients to limit their RPC request limit to 5MB
• 2024-02-07 6:40: We discovered that there might be a bigger issue and the attack can be executed with transactions less than 128KB size.
• 2024-02-07 10:00: We decided for all clients to increase the RPC request limit.
• 2024-02-07 21:00: The fix was merged in geth.
• 2024-02-09: Geth was released

While Geth was the only client affected by this bug, other clients have also updated their defaults to be safe of this attack even if gas limits are increased.
The client teams indicated that the following updates have the safe rpc limits:

Geth: v1.13.12

Nethermind: v1.25.4

Besu: 24.1.2

Erigon: v2.58.0

Reth: v0.1.0-alpha.18

Following the controversy around the LIBRA token, Solana-based token launchpad Pump.fun registered significant decreases in weekly values for new users, token launches, and fees collected.

According to a Dune Analytics dashboard by user evelyn233, the number of new users onboarded in the launchpad fell 16.4% to 601,516 from 719,524 between Feb. 7 and Feb. 13. This is the first time since late November that the new users’ daily average within a week fell below 100,000.

Since the LIBRA incident, the number of tokens deployed weekly has decreased by 26.3%, from 344,607 to 253,955. Despite the decrease, Pump.fun has deployed close to 8 million tokens in 13 months as of Feb. 21.

The launchpad’s fees also slumped due to the smaller number of tokens deployed. From Feb. 7 to 13, 124,623 SOL were collected in fees, falling by nearly 32% to 85,196 SOL the following week. 

Furthermore, this is the first time since the last week of December that the daily average fees collected within a week fell below 15,000 SOL.

Cooling memecoin market

The LIBRA controversy cooled off the memecoin market on Solana. Javier Milei, President of Argentina, endorsed the memecoin LIBRA on Feb. 14 by saying the token was a way to fund Argentinian ventures. 

The token price quickly soared, reaching a $4.5 billion market cap before it crashed 95% over the weekend. 

Despite the crash, a report by Nansen highlighted that two wallets profited over $10 million by buying the token a few seconds after Milei posted about LIBRA on X and selling it at its exact peak price of $4.55.

The episode raised questions about insider trading activity in memecoin markets and prompted debates on how memecoins affect Solana’s trustworthiness. This is potentially a key factor behind Pump. fun’s significant slump in numbers over the past week.

As a result of the debates and the current investor unease toward memecoins, this sector fell 13.4% since Feb. 14 as of press time, registering the third-largest drawdown in altcoin sectors in the period per Artemis’ data.

Mentioned in this article

On 2024-06-23, 00:19 AM UTC, a phishing email was sent out to 35,794 email addresses by updates@blog.ethereum.org with the following content

Users who clicked the link in the email were sent to a malicious website:

This website had a crypto drainer running in the background, and if a user initiated their wallet and signed the transaction requested by their website their wallet would have been drained.

Our internal security team immediately launched an investigation to help determine who launched the attack, what the aim of the attack was, when it happened, who was affected, and how it happened.

Some of the intial actions taken were:

• Prevented the threat actor from sending additional emails.
• Sent out notifications via twitter and email to not click the link in question.
• Closed down the malicious access path the threat actor had used to obtain access into the mailing list provider.
• Submitted the malicious link to various blacklists, and it was then blocked by majority of web3 wallet providers and cloudflare.

Our investigation into the attack showed that:

• The threat actor imported a large email list of their own into the mailing list platform to be used for the phishing campaign.
• The threat actor exported the blog mailing list email addresses, which was a total of 3759 email addresses.
• When we compared the emails in the email list that the threat actor had imported, we could see that the blog mailing list contained 81 email addresses that the threat actor did not previously have knowledge of, and the rest were duplicate addresses.
• Analyzing on-chain transactions made to the threat actor between the time they sent out the email campaign and the time the malicious domain got blocked, appear to show that no victims lost funds during this specific campaign sent by the threat actor.

As we continue working on this incident, we have taken additional measures such as migrating some mail services to other providers, to further help reduce the risk of this happening again.

We are deeply sorry that this incident occurred, and are working diligently with both our internal security team as well as external security teams to further help address and investigate this incident.

Any questions can be directed to security@ethereum.org.