Crypto Deception Unveiled: Check Point Research Reports Manipulation of Pool Liquidity Skyrockets Token Price by 22,000%.

/in

By Oded Vanunu, Dikla Barda, Roman Zaikin

Unmasking Deceptive Tactics: A recent investigation by Check Point Research exposes a troubling trend in the cryptocurrency landscape. Deceptive actors are manipulating pool liquidity, sending token prices soaring by a shocking 22,000%.

$80,000 Heist Unveiled: The manipulation of pool liquidity resulted in a swift and calculated theft of $80,000 from unsuspecting token holders. This incident sheds light on the evolving strategies scammers employ to exploit decentralized finance platforms.

Continued Threat Landscape: This incident follows hot on the heels of a previously reported million-dollar scam. Check Point Research recently delved into the intricacies of a rug pull orchestrated through a fake token factory. For details on this preceding incident, visit Check Point Research: Unraveling the Rug Pull.

Check Point’s Blockchain Threat Intelligence system raised an alert on pool liquidity manipulation, resulting in a staggering token price increase of 22,000%. The malicious actor exploited the liquidity pool, stealing $80,000 from unsuspecting holders.

Check Point’sBblockchain Threat Intelligence system detected a malevolent transaction:
https://etherscan.io/tx/0x85ebb1b1d6f091a2d72c4cffb66beea0552a07b2efabb5fd53d4198f8d159b64

What did we find?

The scammer created two wallets:

0x48F7661E84A823505d683D092a2DccdA1e5aA119

0x151a2498826F9fe6f214C92bB1811f7d1153b630

Using the first wallet, they deployed the contract token WIZ (0x2ae38b2b47bf41ba4ab8f749b092fdd02b00bc1e) and its liquidity pool pair address (0x6e0367d897a8fd8bcbc44b4e2a14bafa904360aa), which included reserves of WETH and WIZ tokens. In the second wallet (0x151a2498826F9fe6f214C92bB1811f7d1153b630), the scammer created a malicious contract (0x796042E0032aC5247bc04A49102d49c5b5A5cF0c) designed to exploit a backdoor and manipulate the WIZ token price, resulting in an $80,000 theft from victims.

Method of Operation:

Token Creation: The scammer launches a new cryptocurrency token, pairs it with a well-known cryptocurrency on a decentralized exchange (DEX), creating a liquidity pool.

Token Promotion: Aggressive marketing, often leveraging social media and influencers, generates hype and attracts investors.

Investor Participation: As investor interest grows, they start purchasing the new token.

Pool Manipulation: After accumulating substantial investments, the scammer manipulates the pool reserve by burning most WIZ tokens, reducing the supply and temporarily inflating the token’s price by 22,000%.

Scammer’s Gain: Exploiting the inflated price, the scammer sells a significant number of tokens, pocketing $80,000.

Technical Insights:

Liquidity pools

In the world of cryptocurrencies, you often need to swap one type of digital currency for another. But how do you do it easily and quickly without an intermediate? That’s where liquidity pools come in. Without these pools, you’d have to find someone willing to trade at the exact time and price you want, which can be difficult and time-consuming.

So how does a liquidity pool work?

Let’s break down the mechanics of a liquidity pool:

Picture a sizable digital reservoir holding two distinct cryptocurrencies—let’s call them Token A and Ethereum. This reservoir serves as an open arena where anyone can swap Token A for Ethereum or vice versa.

Now, when an individual decides to exchange Token A for Ethereum, they contribute Token A to the pool and withdraw an equivalent value of Ethereum. The dynamic pricing within the pool fluctuates based on the quantity of each token present. If there is an abundance of Token A but a scarcity of Ethereum, the value of Token A decreases while Ethereum’s value rises.

In the case at hand, the scammer manipulates the pool balance by burning tokens. Burning tokens within a liquidity pool, like the WIZ/WETH pool, can boost the token’s value by adhering to the core principles of supply and demand. As tokens are permanently removed from circulation, the overall supply diminishes.

Liquidity pools follows a formula that harmonizes the quantities of two tokens. When one token type (WIZ in this instance) undergoes reduction through burning, the relative value of the other token (WETH) in the pool escalates to maintain equilibrium. Failure to increase the amount of WETH leads to a substantial surge in the token price, particularly for WIZ.

Are you seeing how hackers or scammers exploit this method, known as liquidity pool manipulation, to sway token prices?

The crux of this strategy lies in the transient inflation of the token’s price within the liquidity pool. Given that decentralized exchange (DEX) prices hinge on asset ratios in the pool, diminishing one side (via burning) can ditort the price.

Liquidity pools become susceptible to exploitative tactics, including rug pulls or influencing contracts reliant on these pools for price data. This blog zeroes in on the former, unraveling the narrative of a scammer concealing a backdoor to manipulate the WIZ/WETH liquidity pool by incinerating their tokens.So, let us see what the scammer did:

The scammer runs the function ‘brr’ methodID (0x5606de36) on his malicious contract:

let’s see this function:

We can see on line 127 the scammer runs the transfer function on the _coin contract address, the _coin address will be set in an earlier function by the scammer to WIZ address: 0x2ae38b2b47bf41ba4ab8f749b092fdd02b00bc1e

Using this transfer function, the scammer was able to burn the WIZ tokens on the pool, let us understand how :

In order to get to the _burn function the scammer will have to pass a few checks, which we will explore now:

The first check he will need to go through is limitsEnabled, this would have needed to be set to False in order for the scammer to get to the second check.

for limitsEnabled to be False, the scammer needed to run the function called ‘removeLimits’

And as we can see, right before renouncing the ownership of WIZ contract he calls this function:

So this is how the scammer passes the first check.

Now let us look at the second check, in this, the ‘from’ address needs to return False on the ExcludeFromFees and True for isexcludedForMaxTxAmount,

since both functions _isExcludedFromFees and _isExcludedForMaxTxAmount are public, we can run them with the scammer contract address as input and check the results:

Let us look at how the malicious contract address was set to True on the ExcludedForMaxTxAmount, since this is the part that helps us understand that the person who created the WIZ token and the scammer is the same person.

In the WIZ contract code we found a backdoor, the scammer hardcoded the malicious contract address in the code as mktRecevier, and set the excludeFromMaxTranscation to True for this address:

This helps the scammer to pass the second check, and allows him to get to the _burn function.

He then uses this function to burn the WIZ tokens in the WIZ/WETH liquidity pool.

If we will continue to look at the malicious contract code:

We can see the scammer in line 132 of the malicious contract sync the pool and raises the WIZ price. Then at the end in line 137 executes 0xf77 which sells all the tokens and steals almost 80,000 dollars.

As you can see in CoinMarketCap the price of the token raises by 21949% at the time of this malicious transaction:

Scammer’s Strategy:

The scammer’s approach involves temporarily inflating the token price in the liquidity pool. By manipulating the pool balance, they influence the decentralized exchange prices. Liquidity pools, integral to various contracts, become vulnerable to manipulative schemes.

Conclusion:

This manipulation scheme highlights the susceptibility of liquidity pools to fraudulent activities. Scammers leverage backdoors and exploits to manipulate token prices, emphasizing the importance of vigilance in the decentralized finance space.

Check Point researchers are actively monitoring domains associated with the identified scammer’s wallet address and similar. The Threat Intel Blockchain system, developed by Check Point, continues to accumulate valuable information on emerging threats, and this intelligence will be shared in the future. In this collaborative effort, we aim to empower investors with the knowledge needed to navigate the crypto space securely and protect themselves from potential pitfalls. For more information contact us at: blockchain@checkpoint.com

The post Crypto Deception Unveiled: Check Point Research Reports Manipulation of Pool Liquidity Skyrockets Token Price by 22,000%. appeared first on Check Point Research.

Check Point Research – ​Read More

Restricted Settings in Android 13 and 14 | Kaspersky official blog

/in

With each new version of the Android operating system, new features are added to protect users from malware. For example, Android 13 introduced Restricted Settings. In this post, we’ll discuss what this feature involves, what it’s designed to protect against, and how effectively it does its job (spoiler: not very well).

What are Restricted Settings?

How do Restricted Settings operate? Imagine you’re installing an application from a third-party source — that is, downloading an APK file from somewhere and initiating its installation. Let’s suppose this application requires access to certain functions that Google considers particularly dangerous (and for good reason — but more on that later). In this case, the application will ask you to enable the necessary functions for it in your operating system settings.

However, in both Android 13 and 14, this isn’t possible for applications installed by users from APK files. If you go to your smartphone’s settings and try to grant dangerous permissions to such an application, a window titled Restricted Settings will appear. It will say “For your security, this setting is currently unavailable”.

When an application installed from third-party sources requests dangerous permissions, a window pops up with the title Restricted Settings

So, which permissions does Google consider so hazardous that access to them is blocked for any applications not downloaded from the store? Unfortunately, Google isn’t rushing to share this information. We therefore have to figure it out from independent publications for Android developers. At present, two such restrictions are known:

Permission to access Accessibility
Permission to access notifications

It’s possible that this list will change in future versions of Android. But for now it seems that these are all the permissions that Google has decided to restrict for applications downloaded from unknown sources. Now let’s discuss why this is even necessary.

Why Google considers Accessibility dangerous

We previously talked about Accessibility in a recent post titled the Top-3 most dangerous Android features. In short, Accessibility constitutes a set of Android features designed to assist people with severe visual impairments.

The initial idea was that Accessibility would enable applications to act as mediators between the visual interface of the operating system and individuals unable to use this interface but capable of issuing commands and receiving information through alternative means — typically by voice. Thus, Accessibility serves as a guide dog in the virtual space.

An application using Accessibility can see everything happening on the Android device’s screen, and perform any action on the user’s behalf — pressing buttons, inputting data, changing settings, and more.

This is precisely why the creators of malicious Android applications are so fond of Accessibility. This set of functions enables them to do a great deal of harm: spy on correspondence, snoop on passwords, steal financial information, intercept one-time transaction confirmation codes, and so on. Moreover, Accessibility also allows malware to perform user actions within other applications. For example, it can make a transfer in a banking app and confirm the transaction using the one-time code from a text message.

This is why Google deems the permission to access Accessibility particularly perilous — and rightly so. For apps available on Google Play, their use is subject to careful scrutiny by moderators. As for programs downloaded from unknown sources, Android developers have attempted to completely disable access to this set of functions.

Why Google restricts access to notifications

We’ve covered Accessibility, so now let’s talk about what’s wrong with applications accessing notifications (in Android, this function is called Notification Listener). The danger lies in the fact that notifications may contain a lot of personal information about the user.

For example, with access to all notifications, a malicious app can read almost all of the user’s incoming correspondence. In particular, it can intercept messages containing one-time codes for confirming bank transactions, logging in to various services (such as messengers), changing passwords, and so on.

Here, two serious threats arise. Firstly, an app with access to Notification Listener has a simple and convenient way to monitor the user — very useful for spyware.

Secondly, a malicious app can use the information obtained from notifications to hijack user accounts. And all this without any extra tricks, complex technical gimmicks, or expensive vulnerabilities — just exploiting Android’s built-in capabilities.

It’s not surprising that Google considers access to notifications no less dangerous than access to Accessibility, and attempts to restrict it for programs downloaded from outside the app stores.

How Android malware bypasses Restricted Settings

In both Android 13 and 14, the mechanism to protect against the use of dangerous functions by malicious apps downloaded from unknown sources operates as follows. App stores typically use the so-called session-based installation method. Apps installed using this method are considered safe by the system, no restrictions are placed on them, and users can grant these apps access to Accessibility and Notification Listener.

However, if an app is installed without using the session-based method — which is very likely to happen when a user manually downloads an APK — it’s deemed unsafe, and the Restricted Settings function is enabled for it.

Hence the bypass mechanism: even if a malicious app downloaded from an untrusted source cannot access Accessibility or notifications, it can use the session-based method to install another malicious app! It will be considered safe, and access restrictions won’t be activated.

We’re not talking theory here – this is a real problem: malware developers have already learned to bypass the Restricted Settings mechanism in the latest versions of their creations. Therefore, the restrictions in Android 13 and 14 will only combat malware that’s old — not protect against new malware.

How to disable Restricted Settings when installing an app from third-party sources

Even though it’s not safe, sometimes a user might need to grant access to Accessibility or Notification Listener to an app downloaded from outside the store. We recommend extreme caution in this case, and strongly advise scanning such an application with a reliable antivirus before installing it.

To disable the restrictions:

Open your smartphone settings
Go to the Apps section
Select the app you want to remove access restrictions for
In the upper right corner, tap on the three dots icon
Select Allow restricted settings

That’s it! Now, the menu option that lets you grant the app the necessary permissions will become active.

How to protect your Android smartphone

Since you can’t rely on Restricted Settings, you’ll have to use other methods to protect yourself from malware that abuses access to Accessibility or notifications:

Be wary of any apps requesting access to these features — we’ve discussed above why this is very dangerous
Try to install applications from official stores. Sometimes malware can still be found in them, but the risk is much lower than the chance of picking up trojans from obscure sites on the internet
If you really have to install an app from an unreliable source, remember to disable this option immediately after installation
Scan all applications you install with a reliable mobile antivirus.
If you’re using the free version of our protection tool, remember to do this manually before launching each new application. In the paid version of Kaspersky: Antivirus & VPN, this scan runs automatically.

Kaspersky official blog – ​Read More

4th December – Threat Intelligence Report

/in

For the latest discoveries in cyber research for the week of 4th December, please download our Threat_Intelligence Bulletin.

TOP ATTACKS AND BREACHES

Check Point Research provides highlights about Cyber Av3ngers group activity, which has taken responsibility on defacing workstations at Pennsylvania’s Aliquippa municipal water authority. Following the attack, CISA has published an advisory about this hacktivists group which is affiliated to Iranian Revolutionary Guard Corps (IRGC) and reportedly hit multiple water utility companies in the United States by targeting Unitronics’ PLC devices.
The service of 60 United States based credit unions has been disrupted, after Ongoing Operations, a cloud hosting provider firm, has been a victim of a ransomware attack. Security researchers believe that the threat actors had exploited the Citrix NetScaler ‘Citrix Bleed’ vulnerability (CVE-2023-4966) to gain access to the firm’s network.

Check Point IPS provides protection against this threat (Citrix NetScaler Information Disclosure (CVE-2023-4966))

Japan’s space agency, JAXA, has disclosed that it had been hit by a cyber-attack. JAXA claimed that important rocket or satellite related operations information had not been affected, but that the breach is still being investigate. According to Japanese media, the attack had occurred in the summer, and was discovered by Japan’s police a few months later.
Campaigns targeting customers of hospitality reservation service booking.com have recently ramped up. Threat actors target hotels to gain access to their booking.com administration portals. The attackers then contact the hotels’ customers using the official app to redirect the payment to their own accounts.
Official Israeli government agencies have announced that a cyber incident had affected the network of Ziv hospital in Safed. The newly founded hacktivist group Malek Team has taken responsibility for the attack and claims to have exfiltrated 500GB of patients’ medical data from the hospital’s servers.
India’s National Aerospace Laboratories, a government owned firm which develops civilian aircraft, has suffered a ransomware attack on its network. The LockBit ransomware group has claimed responsibility for the breach and has leaked several documents allegedly exfiltrated in the breach.

Check Point Harmony Endpoint and Threat Emulation provide protection against this threat (Ransomware.Win.Lockbit; Gen.Win.Crypter.Lockbit; Ransomware.Wins.LockBit.ta; Ransomware_Linux_Lockbit)

More than $50m in customers’ cryptocurrency has been stolen in a cyber-attack against blockchain platform KyberSwap. According to the company, the attackers used “a series of complex actions“ to exploit a vulnerability and transfer funds from customers’ wallets to their own.

VULNERABILITIES AND PATCHES

Google has released an advisory for Google Chrome addressing seven security vulnerabilities. One of the vulnerabilities, CVE-2023-6345, is a critical integer overflow vulnerability in the Skia 2D graphics library, which could allow a remote attacker to perform sandbox escape. Google claims to be aware of an active exploit for this vulnerability existing in the wild.
Apple has published security updates for its devices’ operation systems to patch the information-disclosure vulnerability CVE-2023-42916. According to Apple, the company is aware of reports of the vulnerability being actively exploited in the wild against previous versions of iOS devices.
Security researchers warn of active exploitation in large scale of OwnCloud vulnerability CVE-2023-49103, a critical information disclosure vulnerability in the graphapi OwnCloud from the last week.
Zyxel has released an advisory addressing 6 security vulnerabilities affecting the company’s NAS devices. Three of the vulnerabilities (CVE-2023-4473, CVE-2023-4474 and CVE-2023-35138) are considered critical and could allow an unauthenticated remote attacker to gain arbitrary code execution.

THREAT INTELLIGENCE REPORTS

Researchers have uncovered a campaign targeting a United States company in the aviation sector. The threat actors used spear phishing emails to gain access to the victim firm’s network, and installed a payload that collects information and creates a reverse shell. The researchers suspect the previously unfamiliar threat actor’s motivation is commercial industrial espionage.
The Ukrainian CERT has published an advisory warning of mass-targeting of Ukrainian citizens with emails leading to Remcos RAT infections. According to the report, the attackers sent malicious court summons to 15,000 Ukrainians using compromised email addresses of official judiciary authorities.

Check Point Threat Emulation provides protection against this threat (RAT.Wins.Remcos.A, Injector.Win.RunPE.A)

A campaign using a modified version of the notorious Gh0st Remote Access Trojan, dubbed SugarGh0st, has been discovered. The threat actors have targeted Uzbekistan’s Ministry of Foreign Affairs, as well as users in South Korea. Security researchers assess that a Chinese nation-state group is behind the attacks.

Check Point Threat Emulation provides protection against this threat (RAT.Win.Gh0stRAT, RAT.Wins.Gh0stRAT)

Researchers warn of a new campaign distributing the Lumma information stealer malware. The attackers had first breached a legitimate website, then use phishing emails to direct victims to the compromised website, causing malicious content to be downloaded.

Check Point Threat Emulation provides protection against this threat (InfoStealer.Win.LummaC2, InfoStealer.Wins.Lumma)

The post 4th December – Threat Intelligence Report appeared first on Check Point Research.

Check Point Research – ​Read More

Taking the complexity out of identity solutions for hybrid environments

/in

For the past two decades, businesses have been making significant investments to consolidate their identity and access management (IAM) platforms and directories to manage user identities in one place. However, the hybrid nature of the cloud has led many to realize that this ultimate goal is a fantasy. Instead, businesses must learn how to consistently and effectively manage user identities across multiple IAM platforms and directories.

As cloud migration and digital transformation accelerate at a dizzying pace, enterprises are left with a host of new identity challenges that many aren’t prepared to deal with. The proliferation of diverse cloud environments, each with its own identity solutions, coupled with the complexities of legacy systems, has resulted in fragmented and siloed identity services. That is where the identity fabric comes in.

The challenge of hybrid identity

Most environments are comprised of a mixture of multiple cloud and on-premise (on-prem) applications and systems. Though many are moving to modern Software-as-a-Service (SaaS) solutions, on-prem IAM products are often deeply embedded in mission-critical systems of organizations. They can’t simply be unplugged and replaced with modernized IAM solutions without risking significant business disruption, loss of data continuity, potential security risks and single points of failure.

Additionally, many modern IAM solutions struggle to meet the complex requirements of large, multi-layered organizations, including user role management, compliance with industry-specific regulations and integration with existing IT infrastructure. It has become painfully evident that a one-size-fits-all IAM system doesn’t exist, forcing organizations to use a combination of IAM systems across hybrid clouds and on-prem. A recent Osterman Research Report found that 52% of organizations stated that addressing identity access challenges in hybrid and multi-cloud environments was a critical initiative for them over the next year.

Managing identity fragmentation

As identity services multiply across hybrid cloud environments, organizations struggle to manage and enforce consistent user policies, comply with changing regulations, gain holistic visibility and mitigate user-related risks. Legacy applications remain tethered to legacy identity solutions, creating an inconsistent user experience without a single authoritative source for a user’s identity. Osterman research showed the top identity initiative for the next twelve months for 64% of the responding organizations was extending cloud identity capabilities to on-prem applications.

What is an identity fabric?

Businesses need a versatile solution that complements existing identity solutions while effectively integrating the various IAM silos that organizations have today into a cohesive whole. To provide consistent security policies and a better user experience, businesses require the ability to quickly audit all authentication workflows, layer intelligence to automate data-driven decisions and empower artificial intelligence (AI) and machine learning (ML) across legacy and on-prem applications in hybrid cloud deployments.

This is where an identity fabric comes into play: to bridge the gap between legacy identity infrastructure and modern cloud-based IAM systems. An identity fabric aims to integrate and enhance existing solutions rather than replace them. The goal is to create a less complex environment where consistent security authentication flows and visibility can be enforced. This approach aligns with our strategy of “taking the complexity out of identity solutions for hybrid environments.”

Learn more about identity fabric

Providing the foundation for an identity fabric

We have found that there are some fundamental building blocks to delivering an effective identity fabric:

The first step is to eliminate the identity silos by creating a single, authoritative directory. It’s critical that this directory be vendor-agnostic so it can stitch together all of your directories to create a single source of truth, management and enforcement. IBM Security Verify Directory offers flexibility, efficiency and scalability across on-prem, cloud and hybrid environments, providing smooth and secure access control.
The next step is to extend modern authentication mechanisms to your legacy applications, which are often abandoned due to the need for more funding, time and/or skills to modify existing application authentication flows. IBM’s Application Gateway is a product-agnostic gateway designed to bridge the gap between legacy and modern apps and systems with no-code integrations that allow legacy applications to take advantage of modern and advanced authentication capabilities, helping to reduce risk and improve regulatory compliance.
The third step incorporates behavioral risk-based authentication for modern and legacy applications. Regardless of the IAM solutions in use, risk-based authentication solutions enable a continuous assessment of risk levels at the time of access. Verify Trust introduces dynamic risk-based authentication, enhancing security without requiring a complete system overhaul. Powered by AI, Verify Trust delivers accurate and continuous risk-based access protection against the latest account takeover techniques by combining global intelligence, user behavioral biometrics, authentication results, network data, account history and a range of device risk detection capabilities.

Explore the Verify family

Orchestration holds your identity fabric together

Orchestration is the integration glue to an identity fabric. Without it, building an identity fabric would be resource-intensive. Orchestration allows more intelligent decision-making and simplifies onboarding and offboarding. It enables you to build consistent security policies while taking the burden off your administrators as you quickly and easily automate processes at scale.

For example, you have a legacy application with a homegrown identity system. The people who wrote it have long since left. Orchestration enables you to create a workflow so that when a user logs in to the system, it automatically creates a user account on the preferred modern identity solution with low code or no code identity orchestration. When users return to that homegrown application, they will automatically access it with a modern authentication mechanism.

Effective identity orchestration allows you to achieve simplicity in legacy and modern application coexistence, remove the burden of identity solution proliferation, consolidate identity silos, reduce identity solution vendor lock-in and simplify identity solution migrations by allowing for highly customizable flows with little-to-no code across identity solutions.

Take the next step in identity solutions

Whether you are an organization looking for workforce access, customer IAM, privileged access or governance identity solutions, or looking to build an identity fabric with your existing identity solutions, IBM Security Verify takes the complexity out of identity solutions for hybrid environments, emphasizing innovation and customer-centricity. We invite all stakeholders to join us on this transformative journey as we shape the future of IAM. Together, we will simplify identity solutions for the ever-evolving world of hybrid environments.

Join us for a webinar to learn more.

The post Taking the complexity out of identity solutions for hybrid environments appeared first on Security Intelligence.

Security Intelligence – ​Read More

How to stop, disable, and remove any Android apps — even system ones | Kaspersky official blog

/in

Most smartphones have an average of around 80 installed apps, of which at least 30% are never used since most are forgotten about. But such “ballast” is harmful: there’s less free space on the device; potential bugs and compatibility issues multiply; and even unused apps at times distract you with pointless alerts.

To make things worse, abandoned apps can continue collecting data about the phone and its owner and feed it to advertising firms, or simply gobble up mobile data. Hopefully, we’ve already convinced you to “debloat” your smartphone at least a couple of times a year and uninstall apps you haven’t used for ages — not forgetting to cancel any paid subscriptions to them!

But, unfortunately, some apps are vendor-protected against uninstallation, and so aren’t all that easy to jettison. Thankfully, there are some ways to get round this problem…

Uninstall the app

Sometimes you can’t find an unwanted app under the Manage apps & device tab of the Google Play app. First, try to remove it through the phone settings: look there for the Apps section. This lists all installed programs and has a search feature to save you from having to scroll through them all. Having found the unwanted app and tapping it, you’re taken to the App Info screen. Here you can view the app’s mobile data, battery, and storage consumption, and, most importantly, find and tap the Uninstall button. If the button is there and active, the job’s done.

List of all installed apps and the App Info screen with the Uninstall button

Disable the app

If the app was installed on the phone by the vendor, it’s likely to be non-removable and have no Uninstall button on the App Info screen. That said, it’s not necessarily linked to the OS or core components of the smartphone — it could be, say, a Facebook client or a proprietary browser. Such apps are often called bloatware since they bloat the phone’s firmware and the list of standard apps. The easiest way to disable such apps is on the above-mentioned App Info screen; instead of Uninstall, the relevant button will be marked Disable. A disabled app is not much different from an uninstalled one — it vanishes from the set of icons on the startup screen and won’t run manually or when the phone boots up. Should you need it later, you can easily turn it back on with a single tap on that same App Info screen.

Disabling reduces the risk of data leakage, but does nothing to save storage space — unfortunately, the disabled app continues to take up memory on your phone. If you absolutely have to uninstall it — but there’s no Uninstall button — read on!…

For non-removable apps, instead of an Uninstall button, the App Info screen shows a Disable button

Stop the app

But what if the Disable button on the App Info screen is grayed out and untappable? For especially important programs, vendors take care to block the disabling option — often for a good reason (they’re vital to the system) — so you need to think very carefully before trying to disable or uninstall such apps manually. Open your favorite search engine and punch in the query “exact smartphone model number + exact app name”. Most likely you’ll see Android user forum discussions at the top of the search results. These often give information about whether the given app is safe to disable or whether there could be any side effects.

To perform a harmless experiment with an app that can’t be disabled, you can use the Force Stop button. This is the second button on that App Info screen and it’s almost always active — even for apps that can’t be disabled. Force Stop simply stops the app temporarily, without attempting to remove or permanently disable it. However, it no longer consumes power or mobile data — and can no longer spy on you. And if your phone continues to work as normal, then perhaps the app isn’t that important after all.

But stopped apps can start up again when certain events occur or after a phone restart, and stopping them manually each time — moreover regularly — can be troublesome and inconvenient. Fortunately, you can automate this task with the Greenify app. It doesn’t require superuser rights to work, but merely automates navigating to the now-familiar App Info screen and tapping the Force Stop button. You simply supply Greenify with a list of unwanted apps and set a Force Stop schedule to, say, twice a day. Other tools offer similar functionality, but Greenify’s advantage is its lack of “extra” features.

If the Disable button is inactive, try using Force Stop

Freeze or uninstall the app despite its objections

If you tested stopping a non-removable app and suffered no negative effects, you might consider freezing it or removing it altogether. Freezing is the same as disabling but is done using different tools. Before delving into the details, note that freezing requires technical skill and the activation of Developer mode on your phone. This mode itself creates certain information security risks by allowing connections to the phone via USB or LAN in special technical modes, plus the ability to view and modify its contents. Although Google has fenced off this functionality with many safeguards (permission requests, additional passwords, and so on), the room for error (thus creating risks) is high.

One more thing: before you start tinkering, be sure to create the fullest possible backup of your smartphone data.

If all of the above hasn’t scared you off, see the guide in the box.

Freezing and uninstalling non-removable Android apps in Developer mode

Download and install Android SDK Platform-Tools on your computer. Of the tools inside, you’ll only need the Android Debug Bridge USB driver and the ADB command line.
Enable Developer mode on your phone. The details vary slightly from vendor to vendor, but the general recipe is roughly the same: repeatedly tap the Build Number option in the About Phone.
Enable USB Debugging under Developer Settings on your smartphone. There are multiple options there — but don’t touch any apart from these two!
Connect your smartphone to your computer through USB.
Allow Debug mode on your phone screen.
Test Debug mode by getting a list of all packages (what developers call apps) installed on your phone. To do so, type the following in the ADB command line
adb shell pm list packages
The response will be a long list of packages installed on the phone, in which you need to find the name of the unwanted app. This might look something like facebook.katana or com.samsung.android.bixby.agent. You can often (but not always) tell which app is which by their names.
Freeze (disable) the unwanted app using the ADB command line. To do so, enter the command
adb shell pm disable-user –user 0 PACKAGENAME ,
where PACKAGENAME is the name of the unwanted app package. Different vendors may have different usernames (0 in our example), so check the correct PM command for your smartphone. As before, an online search helps out: “phone model + Debloat” or “phone model + ADB PM”.
You can use developer commands to not only disable an app but also completely uninstall it. To do so, replace the previous command with adb shell pm uninstall –user 0 PACKAGENAME
Restart your phone.

The free Universal Android Debloater tool somewhat simplifies all this sorcery. It issues ADB commands automatically, based on the “cleaning packages” selected from the menu, which are prepared with both the vendor and model in mind. But since this is an open-source app written by enthusiasts, we can’t vouch for its efficacy.

Kaspersky official blog – ​Read More

What security issues does WordPress have? | Kaspersky official blog

/in

WordPress is the world’s most popular content management system. As its developers like to point out, over 40% of all websites are built on WordPress. However, this popularity has its downside: such a huge number of potential targets inevitably attracts malicious actors. For this very reason, cybersecurity researchers carefully investigate WordPress and regularly report various problems with this CMS.

As a result, it’s not uncommon to hear that WordPress is full of security issues. But all this attention has a positive side to it: most of the threats and the methods to combat them are well known, making it easier to keep your WordPress site safe. That’s what we’ll be discussing in this article.

1. Vulnerabilities in plugins, themes, and the WordPress core (in that order of descending importance)

In all the lists of WordPress security issues available on the internet, it’s things like XSS (cross-site scripting), SQLi (SQL injection), and CSRF (cross-site request forgery) keep popping up. These attacks, alongside various others, are made possible due to vulnerabilities in either the WordPress core software, its plugins or themes.

It’s important to note that, statistically, only a small fraction of the vulnerabilities are found in the WordPress core itself. For example, for the whole of 2022, a mere 23 vulnerabilities were discovered in the WordPress core software — which is 1.3% of the total 1779 vulnerabilities found in WordPress that year. Another 97 bugs (5.45%) were discovered in themes. Meanwhile, the lion’s share of vulnerabilities were found in plugins: 1659 — making up 93.25% of the total.

It’s worth mentioning that the number of vulnerabilities discovered in WordPress should not be a reason to avoid using this CMS. Vulnerabilities exist everywhere; they’re just found most frequently where they’re most actively sought — in the most popular software.

How to improve security:

Always update the WordPress core promptly. Though vulnerabilities are not found as often here, they are exploited more intensively, so leaving them unpatched is risky.
Remember to update themes — especially plugins. As mentioned, plugins are responsible for the vast majority of known vulnerabilities in the WordPress ecosystem.
Avoid installing unnecessary WordPress plugins — those that your site doesn’t need to operate. This will significantly reduce the number of potential vulnerabilities on your WordPress site.
Promptly deactivate or entirely remove plugins you no longer need.

2. Weak passwords and lack of two-factor authentication

The second major security issue with WordPress is the hacking of sites using simple password guessing (brute-forcing) or compromised usernames and passwords (credential stuffing) from ready-made databases, which are collected as a result of leaks from some third-party services.

If an account with high privileges is compromised, attackers can gain control of your WordPress site and use it for their own purposes: stealing data, discreetly adding to your texts links to the resources they promote (SEO spam), installing malware (including web skimmers), using your site to host phishing pages, and so on.

How to improve security:

Ensure strong passwords for all users of your WordPress site. To achieve this, it’s good to apply a password policy — a list of rules that passwords must satisfy. There are plugins available that let you implement password policies on your WordPress site.
Limit the number of login attempts — again, there are plenty of plugins for this purpose.
Enable two-factor authentication using one-time codes from an app. And again, there are WordPress plugins for this.
To prevent your WordPress users from having to remember long and complex passwords, encourage them to install a password manager. By the way, our [KPM placeholder]Kaspersky Password Manager[/placeholder] also lets you use one-time codes for two-factor authentication.

3. Poor control over users and permissions

This issue is connected to the previous one: often, owners of WordPress sites don’t manage the permissions of their WordPress users carefully enough. This significantly increases risk if a user account gets hacked.

We’ve already discussed the potential consequences of an account with high access rights being compromised — including those access rights issued mistakenly or “for growth”: SEO spam injection into your content, unauthorized data access, installing malware, creating phishing pages, and so on.

How to improve security:

Be extremely careful when assigning permissions to users. Apply the principle of least privilege — grant users only the access rights they absolutely need for their tasks.
Regularly review your list of WordPress users, and remove any accounts that are no longer necessary.
Move users to less privileged categories if they no longer need elevated permissions.
Of course, the advice from point 2 also applies here: use strong passwords and enable two-factor authentication.

4. Malicious plugins

Aside from plugins that are “just” vulnerable, there are also outright malicious ones. For example, not long ago, researchers discovered a WordPress plugin masquerading as a page-caching plugin but which was actually a full-fledged backdoor. Its main function was to create illegal administrator accounts and gain complete control over infected sites.

Earlier this year, researchers found another malicious WordPress plugin, which was originally legitimate but had been abandoned by developers over a decade ago. Some bleeding hearts picked it up and turned it into a backdoor — allowing them to gain control over thousands of WordPress sites.

How to improve security:

Avoid installing unnecessary WordPress plugins. Only install the ones truly essential for your site’s operation.
Before installing a plugin, read its user reviews carefully — if a plugin does something suspicious, chances are someone’s already noticed it.
Deactivate or remove plugins you no longer use.
There are plugins that scan WordPress sites for malware. However, keep in mind they can’t be completely trusted: many of the latest instances of WordPress malware can deceive them.
If your WordPress site is behaving strangely and you suspect it’s infected, consider contacting specialists for a security audit.

5. Unrestricted XML-RPC Protocol

Another vulnerability specific to WordPress is the XML-RPC protocol. It’s designed for communication between WordPress and third-party programs. However, back in 2015, WordPress introduced support for the REST API, which is now more commonly used for application interaction. Despite this, XML-RPC is still enabled by default in WordPress.

The problem is that XML-RPC can be used by attackers for two types of attacks on your site. The first type is brute-force attacks aimed at guessing passwords for your WordPress user accounts. With XML-RPC, attackers can combine multiple login attempts into a single request, simplifying and speeding up the hacking process. Secondly, the XML-RPC protocol can be used to orchestrate DDoS attacks on your WordPress website through so-called pingbacks.

How to improve security:

If you don’t plan on using XML-RPC in the near future, it’s best to disable it on your WordPress site. There are several ways to do this. If you need this functionality later, it’s not difficult to re-enable it.
If you intend to use XML-RPC, it’s advisable to configure its restrictions, which can be done using WordPress plugins.
Also, to protect against brute-force attacks, you can follow the advice from point 2 of this article: use strong passwords, enable two-factor authentication, and use a password manager. By the way, this is included in the license of our product designed for protecting small businesses — Kaspersky Small Office Security.

Kaspersky official blog – ​Read More

Vulnerability in crypto wallets created online in the early 2010s | Kaspersky official blog

/in

Researchers have discovered several vulnerabilities in the BitcoinJS library that could leave Bitcoin wallets created online a decade ago prone to hacking. The basic issue is that the private keys for these crypto wallets were generated with far greater predictability than the library developers expected.

Randstorm vulnerabilities and consequences

Let’s start at the beginning. Researchers at Unciphered, a company specializing in crypto wallet access recovery, discovered and described a number of vulnerabilities in the BitcoinJS JavaScript library used by many online cryptocurrency platforms. Among these services are some very popular ones — in particular, Blockchain.info, now known as Blockchain.com. The researchers dubbed this set of vulnerabilities Randstorm.

Although the vulnerabilities in the BitcoinJS library itself were fixed back in 2014, the problem extends to the results of using this library: crypto wallets created with BitcoinJS in the early 2010s may be insecure — in the sense that it’s far easier to find their private keys than the underlying Bitcoin cryptography assumes.

The researchers estimate that several million wallets, totaling around 1.4 million BTC, are potentially at risk due to Randstorm. Among the potentially vulnerable wallets, according to the researchers, 3–5% of them are actually vulnerable to real attacks. Based on the approximate Bitcoin exchange rate of around $36,500 at the time of posting, this implies total loot of $1.5-2.5 billion for attackers who can successfully exploit Randstorm.

The researchers claim that the Randstorm vulnerabilities can indeed be used for real-world attacks on crypto wallets. What’s more, they successfully exploited these vulnerabilities to restore access to several crypto wallets created on Blockchain.info before March 2012. For ethical reasons, they didn’t publish a proof-of-concept of the attack, as this would have directly exposed tens of thousands of crypto wallets to the risk of theft.

The researchers have already contacted the online cryptocurrency services known to have used vulnerable versions of the BitcoinJS library. In turn, these services notified customers who could potentially be affected by Randstorm.

The nature of Randstorm vulnerabilities

Let’s look in more detail at how these vulnerabilities actually work. At the heart of Bitcoin wallet security lies the private key. Like any modern cryptographic system, Bitcoin relies on this key being secret and uncrackable. Again, as in any modern cryptographic system, this involves the use of very long random numbers.

And for the security of any data protected by the private key, it must be as random as can possibly be. If the number used as a key is highly predictable, it makes it easier and quicker for an attacker armed with information about the key-generation procedure to brute-force it.

Bear in mind that generating a truly random number is no stroll in the park. And computers by their very nature are extremely unsuited to the task since they’re too predictable. Therefore, what we usually have are pseudo-random numbers, and to increase the entropy of the generation (cryptographer-speak for the measure of unpredictability) we rely on special functions.

Now back to the BitcoinJS library. To obtain “high-quality” pseudo-random numbers, this library uses another JavaScript library called JSBN (JavaScript Big Number), specifically its SecureRandom function. As its name suggests, this function was designed to generate pseudo-random numbers that qualify for use in cryptography. To increase their entropy, SecureRandom relies on the browser function window.crypto.random.

Therein lies the problem: although the window.crypto.random function existed in the Netscape Navigator 4.x browser family, these browsers were already obsolete by the time web services began actively using the BitcoinJS library. And in the popular browsers of those days — Internet Explorer, Google Chrome, Mozilla Firefox, and Apple Safari — the window.crypto.random function was simply not implemented.

Unfortunately, the developers of the JSBN library failed to make provision for any kind of check or corresponding error message. As a result, the SecureRandom function passed over the entropy increment step in silence, effectively handing the task of creating private keys to the standard pseudo-random number generator, Math.random.

This is bad in and of itself because Math.random is not cut out for cryptographic purposes. But the situation is made even worse by the fact that the Math.random implementation in the popular browsers of 2011–2015 —  in particular Google Chrome — contained bugs that resulted in even less random numbers than should have been the case.

In turn, the BitcoinJS library inherited all the above-mentioned issues from JSBN. As a result, platforms that used it to generate private keys for crypto wallets got much fewer random numbers from the SecureRandom function than the library developers expected. And since these keys are generated with great predictability, they’re much easier to brute-force — allowing vulnerable crypto wallets to be hijacked.

As mentioned above, this isn’t a theoretical danger, but rather a practical one — the Unciphered team was able to exploit these vulnerabilities to restore access to (in other words, ethically hack) several old crypto wallets created on Blockchain.info.

Randstorm: who’s at risk?

BitcoinJS utilized the vulnerable JSBN library right from its introduction in 2011 through 2014. Note, however, that some cryptocurrency projects may have been using an older-than-latest version of the library for some time. As for the bugs afflicting Math.random in popular browsers, by 2016 they’d been fixed by changing the algorithms for generating pseudo-random numbers. Together, this gives an approximate time frame of 2011–2015 for when the potentially vulnerable crypto wallets were created.

The researchers emphasize that BitcoinJS was very popular back in the early 2010s, so it’s difficult to compile a full list of services that could have used a vulnerable version of it. Their report gives a list of platforms they were able to identify as at risk:

BitAddress — still operational.
BitCore (BitPay) — still operational.
Bitgo — still operational.
info — still operational as Blockchain.com.
Blocktrail — redirects to https://btc.com or https://blockchair.com .
BrainWallet — dead.
CoinKite — now sells hardware wallets.
CoinPunk — dead.
Dark Wallet — redirects to https://crypto-engine.org .
DecentralBank — dead.
info (Block.io) — still operational.
EI8HT — dead.
GreenAddress — redirects to https://blockstream.com/green/ .
QuickCon — dead.
Robocoin — dead.
Skyhook ATM — redirects to https://yuan-pay-group.net .

Besides Bitcoin wallets, Litecoin, Zcash, and Dogecoin wallets may also be at risk, since there are BitcoinJS-based libraries for these cryptocurrencies, too. It seems natural to assume that these libraries could be used to generate private keys for the respective crypto wallets.

The Unciphered report describes a host of other intricacies associated with Randstorm. But what it all basically boils down to is that wallets created between 2011 and 2015 using the vulnerable library may be vulnerable to varying degrees — depending on the particular circumstances.

How to protect against Randstorm

As the researchers themselves rightly state, this isn’t a case where fixing the vulnerability in the software would suffice: “patching” wallet owners’ private keys and replacing them with secure ones just isn’t doable. So, despite the fact that the bugs have long been fixed, they continue to affect the crypto wallets that were created when the above-discussed errors plagued the BitcoinJS library. This means that vulnerable wallet owners themselves need to take protective measures.

Because the task of drawing up a complete list of cryptocurrency platforms that used the vulnerable library is difficult, it’s better to play it safe and consider any crypto wallet created online between 2011 and 2015 to be potentially insecure (unless you know for sure that it’s not). And naturally, the fatter the wallet — the more tempting it is to criminals.

The obvious (and only) solution to the problem is to create new crypto wallets and move all funds from potentially vulnerable wallets to them.

And since you have to do this anyway, it makes sense to proceed with the utmost caution this time. Crypto protection is a multi-step process, for which reason we’ve put together a comprehensive checklist for you with loads of additional information accessible through links:

Explore the main crypto threats and protection methods in detail.
Understand the differences between hot and cold crypto wallets, and the most common ways they are attacked.
Use a hardware (cold) wallet for long-term storage of core crypto assets, and a hot wallet with minimal funds for day-to-day transactions.
Before transferring all funds from the old wallet to the new one, equip all your devices with reliable protection. It will guard your smartphone or computer against Trojans looking to steal passwords and private keys or clippers that substitute crypto wallet addresses in the clipboard, as well as protect your computer from malicious crypto miners and unauthorized remote access.
Never store a photo or screenshot of your seed phrase on your smartphone, never post your seed phrase in public clouds, never send it through messengers or email, and don’t enter it anywhere except when recovering a lost private key.
Securely store your private key and the seed phrase for its recovery. This can be done using the Identity Protection Wallet in Kaspersky Premium, which encrypts all stored data using AES-256. The password for it is stored nowhere except in your head (unless, of course, it’s on a sticky note attached to your monitor) and is unrecoverable — so the only one with access to your personal documents is you.
Another option is to use a cold crypto wallet that doesn’t require a seed phrase to back up the private key. This is how, for example, the Tangem hardware wallet works.

Kaspersky official blog – ​Read More

How to protect corporate routers and firewalls against hacking | Kaspersky official blog

/in

Devices on the border between the internet and an internal corporate network — especially those responsible for security and network traffic management — are often a priority target for attackers. They arouse no suspicion when sending large volumes of traffic outward, and at the same time have access to the organization’s resources and to a significant portion of internal traffic. Note also that network activity logs are often generated and stored on these devices, so if the router is compromised, attackers can just erase traces of their malicious activity.

This is why router compromise has become the crown jewels of big-name APTs such as Slingshot, APT28, and Camaro Dragon. But these days far less sophisticated actors can utilize it too, especially if the target company uses outdated, unofficially supported, or small/home office router models.

Attacks on routers and firewalls typically exploit vulnerabilities, which are discovered, alas, with great regularity. Sometimes such vulnerabilities are so serious — yet also so handy for attackers — that some experts wonder whether the backdoors might have been placed in the respective device firmware deliberately. But even if all known vulnerabilities are fixed, various configuration errors, or just incurable features of older router models, can lead to infection. U.S. and Japanese cybersecurity agencies recently published a detailed advisory on an advanced attack of this kind, centered on the activities of the BlackTech (aka T-APT-03, Circuit Panda, and Palmerworm) APT group. The analysis covers the group’s TTP within the infected network, but our focus will be on the most interesting aspect of the report — the malicious firmware.

BlackTech attack on the weak link in corporate defenses

The attack begins with an assault on the target company by infiltrating one of its regional branches. BlackTech actors employ traditional tactics for this, from phishing to exploiting vulnerabilities — with the router attack not yet underway. They take advantage of the fact that branch offices often use simpler hardware and have less rigid IT and infosec policies.

BlackTech then expands its presence in the branch’s network and obtains administrative credentials for the router or firewall. Armed with these, the intruders reflash the edge device with malicious firmware and use its trusted status to launch an attack on the headquarters.

Router compromise mechanics

First, legitimate but outdated firmware is loaded onto the device. Right after rebooting, the hackers modify the program loaded into the device RAM (by hot patching) to disable security features that would normally prevent loading of the modified components (ROMmon). It’s to perform this trick that the old version of the firmware must first be run. After disabling the ROMmon, the modified firmware (and in some cases a modified device bootloader) is uploaded to the router. After another reboot, the router is fully under the attackers’ control.

The modified firmware listens to traffic in anticipation of the “magic” packet that will activate the backdoor. On receipt of this packet, the device gives the attackers full control over its functions, despite them not being on the Access Control List, and allows connection to an SSH session with a specific username but without requiring a password. This user’s actions aren’t logged.

How attackers exploit the router

Malicious router firmware not only provides the intruders with a secure foothold in the target network, but also helps solve a whole range of tactical problems by:

Concealing configuration changes;
Not logging attacker commands and actions;
Blocking execution of some legitimate commands in the router console, hindering incident investigation.

The report focuses on malicious firmware for Cisco routers on the IOS platform, but mentions that BlackTech compromises other models of network equipment in a similar manner. We should add that previous incidents of edge-device compromise affected the Fortinet, SonicWall, TP-Link, and Zyxel brands.

Countering attacks on routers and firewalls

Clearly, an organization is at risk if it uses outdated models of edge network-devices, outdated firmware, or unofficial firmware (this applies not only to Cisco equipment). However, even a new router with fresh firmware can become a useful tool for an attacker, so the various recommendations of the report authors are worth implementing in every network.

Place administrative systems on a separate virtual local area network (VLAN). Block all unauthorized traffic from network devices destined for non-administrative VLANs.

Limit access to administration services to the IP addresses of authorized administrators. Access lists can be applied to all virtual teletype (VTY) lines and specific administrative services. For Cisco routers, it’s recommended to restrict communication with external systems for VTYs using the “transport output none” command.

Monitor both successful and unsuccessful attempts at accessing router administration.

Regularly review network device logs for events such as unexpected reboots, OS version changes, configuration changes, or firmware update attempts. Cross-check against the IT department’s software update plans to ensure each event has been authorized.

Monitor “strange” incoming and outgoing network connections from edge devices. Normally, network devices share routing and network topology information only with nearby devices, and administration, monitoring, authentication, and time synchronization are conducted only with a small number of administrative computers.

Change all passwords and keys at the slightest suspicion that even one password has been compromised.

Upgrade the hardware. Perhaps the most difficult and frustrating of the recommendations. Organizations using outdated models that don’t support secure boot technologies are advised to plan and budget for upgrading this hardware in the shortest time possible. When choosing new equipment, preference should be given to vendors that implement secure development methodologies and a secure-by-design approach.

Kaspersky official blog – ​Read More

Reptar: a vulnerability in Intel processors | Kaspersky official blog

/in

On November 14, Google released a bulletin reporting a serious vulnerability in a number of Intel processors — starting from the Ice Lake generation released in 2019. Potentially this vulnerability can lead to denial of service, privilege escalation, or disclosure of sensitive information. At the time of writing, microcode updates addressing the issue have been released for the 12th and 13th generation Intel processors (Alder Lake and Raptor Lake, respectively). Patches for 10th and 11th generation processors (Ice Lake and Tiger Lake) are in progress. The full list of affected processors is available on the Intel website in the form of an extensive spreadsheet.

According to Intel representatives, the company’s engineers were aware of the processors’ abnormal behavior, but the issue was considered non-critical, and plans to resolve it were postponed to the first half of 2024. However, the situation changed when Google researchers discovered the problem independently. In fact, all of the details about the vulnerability actually come from Google specialists, specifically from this article by Tavis Ormandy.

Processor fuzzing

Tavis Ormandy has discovered numerous major vulnerabilities in various programs and devices. Recently, we wrote about his previous research that found the Zenbleed vulnerability in AMD processors. On that occasion, Tavis talked about adopting fuzzing to find hardware vulnerabilities.

Fuzzing is a testing method that involves feeding random information into the input of the information system being tested. Usually, it’s used to automate the search for software vulnerabilities: a special fuzzing tool is created to interact with the program and monitor its state. Subsequently, tens or hundreds of thousands of tests are conducted to identify unusual behavior in the tested code.

When it comes to testing processors, things are a bit more complicated. We have to generate random programs that operate with no failures of their own and run them on the processor. How can we differentiate normal processor behavior from abnormal behavior in such a case? After all, not every error during software execution leads to a crash. Ormandy proposed a technique in which the same “random” code is simultaneously executed on different processors. Theoretically, the output of an identical program should also be identical; if it isn’t, it could indicate a problem. It was this approach that revealed the vulnerability in the Intel processors.

Useless but dangerous code

To understand how the Reptar vulnerability works, we need to go down to the lowest level of programming — the machine code that processors execute directly. Assembly language is used to represent such basic instructions in a more convenient way. A snippet of assembly language code looks something like this:

Example of code in assembly language. The last line contains a prefix that modifies execution of the instruction following it. Source

The last line features the movsb instruction, which tells the processor to move data from one memory area to another. It’s preceded by the rep modifier, which indicates that the movsb command should be executed several times in a row. Such prefixes are not relevant for all instructions. Intel processors know how to skip meaningless prefixes. Tavis Ormandy gives an example:

Multiple repeated prefixes won’t cause an error when executing the program. Source

Let’s add another prefix, the so-called rex.rxb. It was introduced alongside the x86-64 architecture to handle eight additional processor registers. Although what exactly it does is not that important — all we need to know is that this prefix doesn’t make sense when used with the movsb command:

In theory, the rex.rxb prefix should be skipped, and only the movsb command with the rep prefix executed. But in practice, this isn’t the case for Intel processors. Source

In fact, this prefix changes the behavior of Intel processors (starting from Ice Lake), although it shouldn’t. In this generation of processors, a technology called “Fast Short Repeat Move” was added. It’s designed to accelerate operations involving data movement in RAM. Among other things, this technology can optimize the execution of the rep movsb instruction. Along with the “Fast Short Repeat Move” feature, a flaw crept into the processor’s logic, first discovered by Intel engineers and later by Google experts.

Immediate threat

What could executing this instruction, which disrupts the normal behavior of the processor, lead to? According to Ormandy, the results are unpredictable. The researchers observed execution of random code, parts of the program being ignored, and various failures in the processor, all the way up to complete failure. For the latter, one needs to somehow exploit the vulnerability on a pair of processor cores simultaneously. To check their own systems for this vulnerability, a team of Google researchers prepared a test program.

Unpredictable behavior is bad enough. The most important difference between this “processor bug” and all the others is that it directly threatens providers of virtual private server hosting services, or cloud solution providers in general. This industry is built on the ability to share a single powerful server among dozens or hundreds of clients — each managing their own virtual operating system. It’s crucial that under no circumstances should one client see another client’s data or the data of the host — the operating system managing the virtual containers.

Now imagine that a client can execute a program in their virtual OS that causes the host to crash. At the very least, this could enable a DoS attack on the provider. In fact, Ormandy didn’t present any other exploitation scenarios, citing the fact that it’s very difficult to predict the behavior of a processor operating in black-box mode; although it’s theoretically possible for an attacker to execute specific malicious code instead of relying on random failures. Intel representatives themselves acknowledge that “code execution” and “information disclosure” are possible. Therefore, it’s extremely important to install microcode updates prepared by Intel (for virtual hosting service providers at least).

Kaspersky official blog – ​Read More

What cybersecurity pros can learn from first responders

/in

Though they may initially seem very different, there are some compelling similarities between cybersecurity professionals and traditional first responders like police and EMTs. After all, in a world where a cyberattack on critical infrastructure could cause untold damage and harm, cyber responders must be ready for anything.

But are they actually prepared? Compared to the readiness of traditional first responders, how do cybersecurity professionals in incident response stand up? Let’s dig deeper into whether the same sense of urgency exists in cyber and what security leaders can learn from first responders.

What first responders and cyber IR professionals have in common

Troy Bettencourt, Global Head of X-Force Incident Response at IBM, has responder experience at multiple levels, with a background including military, law enforcement and cybersecurity incident response. According to Bettencourt, there are many parallels between military, law enforcement and cybersecurity incident responders.

“A lot of the things that make military and law enforcement successful — or help contribute to their success — is constant training and drilling,” he said. “When you have an emergency incident, if you’re part of an internal team and something happens, you don’t have to expend a lot of mental energy on the tasks that should be routine.”

To be successful, much like the military and first responders, incident responders in the cyber industry must have clearly defined roles and real-world experience. For example, they shouldn’t have to think about how to do a search in their EDR platform or how to query firewall logs or a SIEM.

“That should be practiced all the time,” Bettencourt said. “If you’re training and drilling that all the time, then you’re not consuming your limited mental energy and creating high stress, and you’re reserving the mental energy for the actual valuable tasks.”

For Bettencourt and the X-Force team, standardization is also key. “We want to make sure we’re approaching our analysis in the same way, so that if you have 50 systems to analyze and you spread that workload, you know that the findings can be trusted, but they’re also complete and that items weren’t missed,” he said.

Challenges for the cyber industry

One of the more tangible challenges for incident response (IR) is an overall commitment to cyber readiness. Unlike first responders, who have developed a high level of preparedness in their protocols, cyber still lags behind.

“There is still quite a ways to go,” said Bettencourt.

He acknowledged that while much of X-Force’s work skews toward large, more mature enterprise clients, some in certain sectors are still less mature. Small to medium-sized businesses and even larger enterprise organizations that don’t have the resources to invest in cybersecurity often lack the readiness for IR processes.

“Hopefully, it’s not viewed as an obstruction. The business has to adopt cybersecurity as part of the business and not as just a regulatory component that has to be complied with. Because the barrier to entry for cyber criminals has greatly diminished. It’s so easy to jump on the Dark Web and start getting tools and buying malicious Software-as-a-Service kits. It doesn’t take much to be a cyber criminal.”

But lurking in the shadows of the tangible challenges lies an intangible obstacle: responder burnout and stress. According to Bettencourt, studies have shown that, whether it’s cybersecurity, law enforcement, military or high-risk jobs, people often go over and above and beyond because of their team.

“They don’t want to let the team and their team members down,” he said.

With that responsibility, many IR professionals are often self-sacrificing and don’t look out for their own well-being. This can lead to significant burnout and stress.

“Now you have diminishing returns. You have talent retention issues, not just for the company, but for the field in general.”

Adopting the right mindset for IR success

To address the readiness challenges and keep pace with first responders, Bettencourt suggests the enterprise focus on three key areas.

Adaptability

While heavy standardization has its advantages, Bettencourt advises that organizations remain flexible. Especially in a field where technology and threat approaches are constantly changing and there is a constant desire to learn.

“Getting set in your ways in this field is a death knell from a career perspective because it’ll rapidly move past you,” he said. “I left the field for about three years, and it was like drinking from a fire hose when I got back — and I had been doing it for about six years before that.”

Encourage smaller teams

Building a small team culture has produced favorable results for the X-Force team.

“It’s an approach that benefits both the individual and the organization,” he said. “I think leaders really need to try to foster that structure, that culture of small teams where you can rely on each other, and by extension, people will go above and beyond because of their teammates. They don’t want to let their team down, which means they don’t want to let the business or clients down.”

Prioritize mental health

While mental health assistance is readily available in the cyber industry, it’s not discussed enough compared to first responders, where accessing such resources has become more normalized over time.

When it comes to trauma in first response jobs compared to IR and cybersecurity, Bettencourt noted that while there may not be as much physical trauma for cyber, the constant stress of working can build up over time and cause strain.

“Being an individual contributor burned me out,” he admitted. “At one point it was four months straight of 60 and 70-hour weeks. All I worked was ransomware and nation-state engagements, and it became too much for me and my family.”

Preventing burnout improves IR

Long hours are, unfortunately, very common in the field. So how can leadership develop the right mindset to reduce burnout?

“If you’re a business that just cares about the bottom line [and not your personnel], keeping responders happy is going to result in better performance and less attrition, which means less talent acquisition costs. In cyber, it still takes time to bring them up to speed. For IR, generally, if you lose somebody, it’s about six months before you get a replacement that can really contribute, which then means you’re burning your other folks out,” Bettencourt said.

“So from a purely business, mercenary perspective, even if your organization is not employee-focused, it makes sense from the standpoint of performance, client satisfaction, delivering quality outcomes — from the standpoint of nurturing talent, maintaining talent, reducing talent acquisition and retention costs. To me, it’s a no-brainer. You have happier people, and when people are happy, they will typically work harder for you.”

By learning some lessons from first responders, organizations can be ready to face whatever the next cyber crisis brings.

To learn how IBM X-Force can help you with anything regarding cybersecurity including incident response, threat intelligence or offensive security services schedule a meeting here.

If you are experiencing cybersecurity issues or an incident, contact X-Force to help: US hotline 1-888-241-9812 | Global hotline (+001) 312-212-8034.

The post What cybersecurity pros can learn from first responders appeared first on Security Intelligence.

Security Intelligence – ​Read More