Man ‘hacks’ IndiGo website to find lost luggage, airline says ‘at no point…’
https://lm.facebook.com/l.php?u=https%3A%2F%2Fwww.hindustantimes.com%2Findia-news%2Fman-hacks-indigo-website-to-find-lost-luggage-airline-says-at-no-point-101648687010363.html&h=AT3mj7855Rbn1ZGwXUOBKLc9b-yxfFDsoY-Zn0v9QK7PcEOrLaOSx__HyHNYa8u_60r70xT88Fi2qWSI7YapOcD1QgjsOY1D_AotO4SGJJwCOkbaCC00g4G_4P9P87jOqg

An IndiGo passenger has claimed to find a “vulnerability” in the airline’s website using which he was able to find the phone number of a co-passenger with whom his bag was mistakenly swapped. In a series of tweets, a user, who goes by the name Nandan Kumar, explained how he was able to find that IndiGo’s website “leaks sensitive data” which the airlines need to “get it fixed”.

When the IndiGo passenger didn’t get any call in the morning, he started digging into the airline’s website by using the co-passenger’s PNR, or Passenger Name Record, written on the bag tag.

“So now, after all the failed attempts, my [developer] instinct kicked in and I pressed the F12 button on my computer keyboard and opened the developer console on the @IndiGo6E website and started the whole checkin flow with network log record on,” he tweeted.

He said he was finally able to find the phone number and email ID of his co-passenger.

“I made note of the details and decided to call the person and try to get the bags swapped,” Kumar wrote on Twitter as he advised IndiGo to improve its customer care service and IVR.

IndiGo said in a statement that its IT processes are “completely robust and, at no point was the IndiGo website compromised.”

There is a terrifying and highly effective “method” that criminal hackers are now using to harvest sensitive customer data from Internet service providers, phone companies and social media firms. It involves compromising email accounts and websites tied to police departments and government agencies, and then sending unauthorized demands for subscriber data while claiming the information being requested can’t wait for a court order because it relates to an urgent matter of life and death.

What is Axie Infinity?
A green fuzzy creature with dizzy-looking eyes, a cactus on its forehead, and a pumpkin on its back

Axie Infinity is a play-to-earn game with mechanics quite similar to Pokémon battles. Each player assembles a team of critters called “Axies”, which have different traits and strengths, and can be battled against other players’ teams. These Axies are somewhat pricey—the price fluctuates and depends quite a bit on which Axie you wish to buy, but the cheapest ones (prior to the hack) were around $25 each. During peak Axie popularity, the cheapest Axies cost more than $100.1 Given that a player needs at least three Axies to play, this is a substantial barrier to entry, and so “scholarship programs” have developed in which organizations buy the Axies and provide them to players, who in turn give the “scholarship” organization a cut of their earnings. This has resulted in many such organizations relying on players located where wages are low—more than half of Axie players were based in the Philippines as of November 2021. During May–August 2021, back when the game’s economy was fairly nascent and had not yet hit an inflection point with regards to its inevitable inflation, skilled players were able to make considerably more than the roughly $41/day average wage in the Philippines, even after accounting for the cut taken by the scholarship organizations. By November 2021, only the skilled players were making above even minimum wage—and only barely—despite the continuing narrative that Axie was changing lives in the Philippines by allowing people to play video games for a living.2

How does it work?

After assembling their team of “Axies”, bought with WETH, players battle against each other to earn “smooth love potions” (SLP). These SLP can then be spent to breed Axies, or cashed out into other forms of cryptocurrency and then, potentially, into real-world money. Axie Infinity also has a separate token, AXS, which is used both for governance and for breeding, and another token, RON, which is used to pay transaction fees. There are, of course, speculative markets for each of these. Ronin also supports USDC, a stablecoin that is pegged to the US dollar, for people who like to hedge against the volatility of the other supported tokens. And finally there are the NFTs—the Axie characters that are battled, bred, bought, and sold are each represented as an NFT. Are you keeping up?

Why doesn’t the game just use the Ethereum network, like so many other applications? Well, it does, sort of. The problem with the Ethereum network is that it’s quite slow and expensive to use. Depending on network congestion, transactions can take minutes or even days to be confirmed, and if you want your transactions to go through more quickly you have to pay more. Transaction fees cost between a few dollars and many tens of dollars. This is not exactly a hospitable environment in which to build a video game.

So, Sky Mavis (the company behind Axie Infinity) created what is called a sidechain. It’s based on the same protocol as Ethereum, but it operates independently from the Ethereum mainnet and uses a different consensus mechanism. Instead of the Ethereum miners that continuously grind away solving math problems in hopes of validating the next transaction (proof-of-work), the Ronin sidechain is based on proof-of-authority—that is, all of the validators are operated by known, trusted parties, and so don’t have to do all that expensive work to establish that they’re following the rules. It is more efficient than proof-of-work, but at the expense of decentralization.

So how does one get their crypto to Ronin, or cash out their Ronin crypto? And how does one “wrap” their Ether? This is where the Ronin Bridge comes in. Although Binance and two other (small) exchanges that support the Ronin network allow users to exchange some of the tokens from Ethereum to Ronin and back again, the safest and most common way people move their tokens around is via the Ronin Bridge. A bridge is really just two corresponding smart contracts on two networks—in this case, one on the Ethereum network, and one on the Ronin network. When someone sends a token like ETH to the Ronin Bridge, it is “locked” in the Ronin bridge—held so that it can’t be spent elsewhere on the Ethereum network. Simultaneously, the contract on the Ronin side creates an equivalent token—WETH—and deposits it into the user’s Ronin wallet. To the user it looks like their Ethereum moved from one network to the next, but the details of how this works are important.

Blockchain bridges work somewhat like a casino. When you go to a casino, you take your regular dollars and trade them for casino chips. You can do whatever you please with your casino chips inside the casino, but they’re not much use to you anywhere else. When you’re all finished, you go back to the desk and trade your casino chips back out for dollars. Although they’re just plastic, your stack of casino chips might represent quite a lot of money. But if something happened such that the person at the desk no longer had sufficient cash for you to cash out your casino chips, you might suddenly find your stack of chips aren’t worth very much.

The hack

As I mentioned earlier, the Ronin network relies on a number of trusted validators to process transactions in the network. As it turns out, there were only nine validators in total (Ethereum, by comparison, has thousands of miners). This increased the risk of what is known as a 51% attack—when a malicious actor is able to compromise more than half of the validators on the network—since the attacker only needed to compromise five of the nine validators. And sure enough, an attacker was able to compromise four of the validators run by Sky Mavis, plus a fifth validator run by Axie DAO (a community-run organization supporting the Axie Infinity project). They then forged withdrawals, used their five compromised validators to validate the transactions, and drained 173,600 ETH and 25.5 million USDC that had been locked in the bridge. At today’s prices, assuming they were able to cash it out, this would be more than $625 million.

My thoughts

This is just a shocking amount of money. This appears to be the largest hack in the history of defi—at least in terms of the value of money at the time of theft. It’s second to the August 2021 Poly Network hack of $611 million, although in that case the majority of those stolen funds were later returned by the exploiter, who claimed to have been a white hat hacker demonstrating the vulnerability.4

I’m quite concerned for the Axie userbase, given the narrative that playing Axie Infinity can become someone’s job—particularly in developing countries.

Molly White:
An analysis of the Axie Infinity hack: Sky Mavis taking six days to disclose is irresponsible and users likely lost money they need to live, not just spare cash

The Axie Infinity hack, what happened, and why people keep talking about bridges

I was also startled by Sky Mavis’s claim that they were not aware of the hack (perpetrated on March 23) until March 29 when a user reported issues withdrawing funds. If we take them at their word, that means they were missing $625 million for six days without realizing it, which is jaw-dropping. The alternative explanation is that they were aware and didn’t publicly announce it, which would mean they left their bridge and exchange operational for days despite a huge vulnerability, and were allowing users to buy in and transact with tokens that were largely unbacked. Either they are handling money in a completely irresponsible way, or they acted irresponsibly toward their users, and neither is good.

As far as the attacker, they have transferred relatively little out of the wallet that is known to be associated with the hack. This is somewhat unusual—typically after big hacks like this we see the hackers try to launder the crypto as quickly as they can before exchanges start freezing wallets. Sky Mavis has spoken about trying to recover the stolen funds—I think only time will tell how that goes. It’s not an easy task, but $625 million is certainly a strong motivator both for Sky Mavis, their investors, and law enforcement.

If Sky Mavis doesn’t recover the funds, they’re in a tough spot. The various tokens that operate on the Ronin network are now majorly unbacked. They could go the Wormhole route, and come up with $625 million to restore backing.6 I would say this seems unlikely, but I would’ve said Wormhole coming up with $320 million was unlikely too, and I was shown to be wrong on that one. The company lists some pretty big names among its investors—they raised $152 million in Series B funding in October 2021 from firms including Andreessen Horowitz, Accel, and Paradigm, valuing the company around $3 billion.

Sky Mavis has been continuing to make promises to reimburse their users regardless of whether the funds are recovered. However, even if they know they won’t be able to come up with that kind of money, they have a strong incentive to keep people believing that they can: the promise of a bailout is likely the only reason the various Axie tokens have any value left at all. The tokens have plummeted in value, but not to zero—we saw a similar thing happen in the aftermath of the Wormhole exploit, which seemed to be users holding out for good news.

https://web3isgoinggreat.com/?id=2021-08-11-0

Wyze Cam flaw lets hackers remotely access your saved videos
https://www.bleepingcomputer.com/news/security/wyze-cam-flaw-lets-hackers-remotely-access-your-saved-videos/

A Facebook bug led to increased views of harmful content over six months
https://www.theverge.com/2022/3/31/23004326/facebook-news-feed-downranking-integrity-bug?scrolla=5eb6d68b7fedc32c19ef33b4

The social network touts downranking as a way to thwart problematic content, but what happens when that system breaks?

IT giant Globant has confirmed suffering a data breach after the notorious hacker group Lapsus$ leaked tens of gigabytes of data allegedly stolen from the company.

Earlier this week, the hackers made public roughly 70 Gb of source code allegedly belonging to Globant customers. Folder names suggest that some of the source code belongs to major companies, including Apple and Facebook.

The group has also published a list of usernames and passwords that they claim can be used to access various development platforms used by Globant.

In a statement issued on Wednesday, Globant said it has activated security protocols and launched an investigation after detecting unauthorized access to a “limited section” of its code repository.

“According to our current analysis, the information that was accessed was limited to certain source code and project-related documentation for a very limited number of clients. To date, we have not found any evidence that other areas of our infrastructure systems or those of our clients were affected,” Globant stated.

The company has more than 23,000 employees and a presence in 18 countries. Its customers include Google, Electronic Arts, and Rockwell Automation.

Lapsus$ has taken credit for attacks on several other major companies, including Microsoft, Okta, Samsung, Vodafone, Ubisoft and NVIDIA.

The Federal Bureau of Investigation (FBI) this week announced the arrests of 65 individuals as part of an international effort to combat business email compromise (BEC) fraud.

BEC scammers typically target employees in charge of making or authorizing wire transfers, from either a compromised or a spoofed email account.

Using these accounts, the fraudsters send legitimate-looking requests for wire transfers to bank accounts that they control.

These attacks have been observed worldwide, and last year alone the FBI’s Internet Crime Complaint Center (IC3) received reports of attacks that caused adjusted losses close to $2.4 billion.

Named Operation Eagle Sweep, the newly announced BEC crackdown started in September and resulted in the arrests of suspects in the United States (43), Nigeria (12), South Africa (9), Canada (2), and Cambodia (1).

Global Operation Disrupts Business Email Compromise Schemes
FBI, International Partners Carried Out Operation Eagle Sweep to Combat Financially Devastating Crime
https://www.fbi.gov/news/stories/coordinated-operation-disrupts-global-bec-schemes-033022

On 15th March, OpenSSL has published an advisory that talks about a high severity vulnerability in its software library. The flaw that is tracked as CVE-2022-0778 with a base score of 7.5 in CVSS3.1 would lead to a denial-of-service (DoS) condition in OpenSSL when parsing certificates. Since the flaw allows attackers to crash servers, it is important to learn How to Fix CVE-2022-0778- A Denial-of-Service Vulnerability in OpenSSL.

The Summary Of CVE-2022-0778- A Denial-Of-Service Vulnerability In OpenSSL:

Any process that parses an externally supplied certificate may be subject to a denial of service attack since certificate parsing happens prior to verification of the certificate signature. This allows forming an infinite loop in the process of parsing crafted private keys if they contain explicit elliptic curve parameters. Usually, an attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature as per OpenSSL.

The advisory explains a few circumstances in which the flaw can be exploited. There are:

TLS clients consuming server certificates.
TLS servers consuming client certificates.
Hosting providers taking certificates or private keys from customers.
Certificate authorities parsing certification requests from subscribers.
Anything else which parses ASN.1 elliptic curve parameters.
Applications that use the BN_mod_sqrt() where the attacker can control the parameter values.

How To Fix CVE-2022-0778- A Denial-Of-Service Vulnerability In OpenSSL?

OpenSSL addresses the vulnerabilities in its new releases. OpenSSL has rolled out three new versions with the patch. All are suggested to find out the current version of OpenSSL on their machines and upgrade to the corresponding suggested versions.
OpenSSL 1.0.2 users should upgrade to 1.0.2zd (premium support customers only)
OpenSSL 1.1.1 users should upgrade to 1.1.1n
OpenSSL 3.0 users should upgrade to 3.0.2

Cybersecurity, cloud, storage and other vendors are assessing the impact of a recent OpenSSL vulnerability on their products and services.

Updates released by the OpenSSL Project earlier this month patch a high-severity denial-of-service (DoS) vulnerability related to certificate parsing.

The security hole, tracked as CVE-2022-0778 and reported by Google vulnerability researcher Tavis Ormandy, affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It has been fixed with the release of versions 1.0.2zd, 1.1.1n and 3.0.2.

Exploitation of the vulnerability is possible in certain situations, and it can lead to a DoS attack against a process that parses externally supplied certificates.

Technical details and at least one proof-of-concept (PoC) exploit are publicly available, and companies whose products and services rely on OpenSSL have started assessing its impact.
https://github.com/drago-96/CVE-2022-0778

Red Hat initially said it was not directly affected by the flaw, but further investigation revealed that some versions of Red Hat Enterprise Linux are vulnerable to DoS attacks. Other Linux distributions have also released advisories.
https://access.redhat.com/security/cve/cve-2022-0778
https://www.freebsd.org/security/advisories/FreeBSD-SA-22:03.openssl.asc

https://access.redhat.com/security/cve/cve-2022-0778
While Red Hat initially stated not to be directly affected by this flaw, after further investigation we found that the versions of OpenSSL as shipped in Red Hat Enterprise Linux 6, 7, and 8 are vulnerable to a denial of service attack through malicious Elliptic Curve parameters. During processing of the parameters OpenSSL will call BN_mod_sqrt() with invalid arguments, causing the process to enter an infinite loop. The invalid EC parameters can be provided to OpenSSL through X.509 certificates (used in TLS connections), through public and private keys, through certificate signing requests and other places where applications process Elliptic Curve parameters. The flaw has been rated as having a security impact of Important. A future update will address this issue in Red Hat Enterprise Linux 6, 7 and 8.
Red Hat has investigated whether a possible mitigation exists for this issue, and has not been able to identify a practical example. Please update the affected package as soon as possible.
CVSS v3 Base Score 7.5