Research by: Haifei Li, Check Point Research

Introduction

Outlook, the desktop app in the Microsoft Office suite, has become one of the world’s most popular apps for organizations worldwide for sending and receiving emails, scheduling conferences, and more. From the security perspective, the app is one of the critical “gateways” responsible for introducing various cyber threats into organizations. Even a minor security problem in this app could cause severe damage and undermine the overall enterprise security.

Therefore, it is essential to examine the attack vectors on Outlook for typical enterprise environments, which Check Point Research will do in this paper. We assume the position of an average user – we click and double-click on things on Outlook – as our daily work requires, and we examine the security risks they may introduce from a security research perspective.

We will examine the attack vectors in three categories: the “obvious” Hyperlink attack vector, the “normal” attachment attack vector, and the “advanced” attack vector regarding Outlook email reading and ‘special object’. We use section numbers to mark the scenario for each attack vector.

Please note that the discussed research in this paper was performed on the latest Outlook 2021 (desktop version on Windows), with the latest security updates installed as of November 2023, in typical/default Outlook + Exchange Server environments.

I – The Obvious: the Hyperlink Attack Vector

1.1 – ONE Single-click: Web Links

If an attacker wants to attack someone via emails, an obvious method is for the attacker to send emails with malicious web hyperlinks to lure the victim to click on the links in these HTML emails. This is in fact the attack vector for all the phishing emails that the industry has been fighting against every day.

For example, the following is an email we received – the email body is written in HTML and has some links, such as “https://www.microsoft.com”. When the user clicks, Outlook calls the default browser on the OS to browse the website, which is just obvious.

Figure 1 – gif showing web links in Outlook email

For this attack vector, the attacker basically uses emails as a “bridge” to perform web-based attacks, whether they are social-engineering-based phishing attacks, browser exploits, or even highly technical browser zero-day exploits.

Please note that only a single click is needed to launch web links on Outlook. No additional confirmation is needed by the users. While this may sound scary (compared to the next attack vectors we will discuss), the security risks are not in Outlook, but in the browsers. If the browser is strong enough (against browser exploits) and the user is smart enough (against phishing attacks), there would be no problem. That is probably why Outlook considers usability as the first criteria here; another reason could be that email hyperlinks are just too common, you cannot let users confirm every click, because that would be too annoying and take too much time.

1.2 – Not all hyperlinks are web links

However, Outlook hyperlinks are not just web links, they could contain other types of hyperlinks, and those may introduce security risks. In fact, we at Check Point Research have discovered an Outlook bug in this attack vector. However, discussing particular bugs is not the goal of this paper. Therefore, we’d like to leave this topic for another publication. Please watch our blog site if you are interested. We will update here when the blog post is available.

II – The Normal: the Attachment Attack Vector

Here is the normal attack vector: the attacker sends the victim an email with a malicious attachment and lures the victim to open the attachment.

The “opening the attachment” on Outlook could mean two different types of actions. When the user double-clicks on the attachment, the system is trying to call the default registered application (for that attachment file type) on Windows to open the attachment in that application. When the user single-clicks on the attachment, it is trying to call the registered “previewer” application (for that attachment file type) to preview the attachment within the Outlook app. We will discuss both in detail.

The security risk introduced in the “attachment” scenarios depends on the security of the registered application for that attachment file type. If the application is robust enough with proper security measures, it would be less risky for the end user. On the other hand, if the application is insecure, it would be more risky for the end user.

2. 1 – Double-clicking: Opening the Attachment

If the user double-clicks on the attachment, Outlook will try to call the registered application (for the file type of the attachment) to open the attachment. Depending on the attachment’s extension name (the file type), there could be three scenarios.

2.1.1 – NO CLICK: The attachment’s extension name is marked as an “unsafe” file type.

The attachment could not be opened by Outlook (but it could be received, though).

The following figure shows a “.vbs” attachment is received but the user could not open it, because the “.vbs” file type is marked as “unsafe” by Outlook.

The blocked unsafe file types on Outlook are listed here by Microsoft.

2.1.2 – ONE DOUBLE-CLICK AND ONE SINGLE-CLICK: The attachment’s extension name is not marked as “unsafe” and not marked as “safe” either.

You may consider this as the “unclassified category”. In this scenario, there would be a promoted dialog shown to the user, asking the user for confirmation to open the file.

In this scenario, the user needs to perform two clicks in order to open the attachment. One is double-clicking on the attachment; the other is clicking the “Open” button on the promoted dialog (not the default button). After that, the default/registered app for this specific file type on the Windows OS would be used to open the attachment.

In Check Point Research’s recent blog post, we disclosed an interesting attacking technique (leaking NTLM information via common ports like 80/443) whereby the attacker delivers the .accdb exploit via emails; this would also fall into this scenario. The following gif shows this in an intuition way.

Figure 3 – gif showing double-clicking to open .accdb attachment on Outlook

In the real world, there are so many file types in this “unclassified” scenario. For an average Outlook user, it is impossible to know if every app/attachment you open is secure enough. Therefore, we recommend users stay cautious against this attack vector: do not easily click on the additional “Open” button for attachments from untrusted persons.

For application developers, while it is still rare in the real world, a good recommendation is to honor the Mark-of-the-Web (MotW). In this scenario, the attachment is marked as “from the Internet” when it’s sitting in the Outlook temporary directory prior to being opened by the third-party app. Therefore, if the third-party app checks and honors the MotW, like limiting the features and/or opening the app in an application sandbox when it detects that the file has the MotW flag, it would be a very good security practice.

Knowledge note: on default Outlook + Exchange Server environment, MotW is only set for attachments from email addresses outside the organization’s domain (the Internet), but not for email addresses inside the organization. Therefore, the MotW is very good for developers to balance security and usability for their apps.

For example, on February 2023 Patch Tuesday, Microsoft released a “defense in depth” feature via CVE-2023-21715 for Microsoft Publisher, a Microsoft 365 app. What the update does is simply disable Macros on Publisher totally when the .pub file has MotW. According to our research, when a .pub file with Macros embedded is opened by Publisher, in a “pre CVE-2023-21715” environment, if the .pub file has MotW (an external .pub attachment would fall in this attacking scenario), the following warning dialog is provided to the end user.

In the “post CVE-2023-21715” environment, the dialog is changed to:

Note the difference, there’s now no option for the user to choose to run Macros inside the .pub file when the file comes with MotW (from the Internet), making it secure for the end user.

2.1.3 – ONE DOUBLE-CLICK: The attachment’s extension name is marked as a “safe” file type.

In this scenario, the attachment would be opened directly when the user double-clicks on the attachment.

Check out the following gif where the user opens a .docx file directly via one double-click because the .docx is marked as a “safe” file type.

Figure 6 – gif showing double-clicking to open .docx attachment on Outlook

Since there is no additional confirmation for users prior to opening the attachment in this scenario – one double-click is enough to call the application to open the attachment. Application developers should be extremely careful to register their file types/applications into this category.

A highly recommended security enhancement is developing an application sandbox for your application and processing the file in it, like Word, Excel, and PowerPoint’s “Protected View” mode. That said, the Word (.docx, .doc, .rtf, etc.), Excel (.xlsx, .xls, etc.), and PowerPoint (.pptx, .ppt, etc.) file types are all registered in this “safe” category, as well as the popular PDF file type for the latest Adobe Acrobat Reader (tested on version 2023.006.20360).

Figure 7 – Word running in Protected View mode (process integrity level “AppContainer”) when opening a document from external emails

The Protected View mode on Word/Excel/PowerPoint is not a typical application sandbox. In fact, beyond processing the file in the sandboxed process, it also limits the features that could run when the app is running in Protected View mode. For example, all OLE-related features are disabled when Protected View mode is activated. Therefore, the Protected Mode on Word/Excel/PowerPoint is much stronger than typical application sandboxes from a security point of view.

2.2 – Single-clicking: Previewing the Attachment

If the user single-clicks on the attachment (compared to double-clicking), Outlook will try to call the registered “previewer” app (for the file type of the attachment) to “preview” the attachment inside Outlook. Even though it’s called “preview”, the attachment file is still opened and processed from the technical point of view. The difference is that when previewing, the third-party app is running as a COM server in the background, and the attachment content is displayed in the Outlook window. As previously discussed, when “opening” the attachment via double-clicking, the third-party app is run directly, and the content is displayed in the application’s window.

Depending on the attachment’s extension name (the file type), there could be four scenarios when previewing the attachment.

2.2.1 – NO PREVIEW: The attachment’s extension name is marked as “unsafe”.

This is the same situation as we discussed in Scenario 2.1.1. Since the attachment is totally disabled, there are no opening or previewing options.

2.2.2 – NO PREVIEW: There’s no registered previewer app for the extension name.

In fact, most of the file types we have seen are in this category because most apps handling the file types are not registered as Outlook previewer apps. Check out the following gif where the user attempts to preview (via a single-click) a .wmv file (a media file type) but there is no registered app for that file type, so an error message is displayed.

Figure 8 – gif showing single-clicking trying to preview a .wmv attachment on Outlook but receiving an error message

2.2.3 – TWO SINGLE-CLICKS: The previewer app is registered but needs additional confirmation to preview the content

There are some file types, that have their previewer apps registered but Outlook doesn’t have much confidence that previewing the attachment is safe, so Outlook gives an additional warning dialog to the user – which requires another single click – to confirm to preview the attachment. Therefore, there are two single-clicks in this scenario, one for single-clicking on the attachment, and the other for clicking on the “Preview file” button on the warning window.

The following example previews a .pdf attachment – a popular file type- when Adobe Acrobat Reader is installed on the OS. When the user single clicks on the attachment, Outlook asks if the user wants to continue the previewing. Additionally, there’s an option letting the user choose if he/she wants to confirm this file type every time.

Figure 9 – gif showing single-clicking to preview a .pdf attachment on Outlook

Note that in the background, the PDF attachment is processed in the Adobe Acrobat Reader sandbox (one of the ”Acrobat.exe” processes with integrity level “Low”). The Adobe Acrobat Reader processes are started by the Windows process “prevhost.exe”. As shown in the following figures.

Figure 10 – Adobe Acrobat Reader runs in the background and processes the attachment in sandboxed environment, when user previews a PDF attachment on Outlook

Knowledge note: In Windows, standard/default users start processes with the “Medium” integrity level, so if a process is running with a lower integrity level (“Low” or “AppContainer”), it usually indicates that the process is running with a restricted application sandbox. Read more here.

2.2.4 – ONE SINGLE-CLICK: Previewer app is registered and marked as “safe”.

This scenario is the smoothest way to read the content of an attachment. When the user just single-clicks on the attachment, the attachment is previewed and the content is displayed in the Outlook window.

Because the process is very smooth, the potential security risk it may introduce is high. Therefore, from a security point of view, only the apps that have robust security enhancements should be registered into this “previewing safe list”.

For example, the Word, Excel, and PowerPoint file types are in this list. Following is a gif showing a .docx attachment being previewed on Outlook.

Figure 11 – gif showing single-clicking to preview a .docx attachment on Outlook

And, when previewing Word, Excel, or PowerPoint attachments on Outlook, the corresponding app is always run in the security-strong Protected View mode, as the following figure shows. So it protects users while also offering great usability.

Figure 12 – Microsoft Word runs in the background and processes the attachment in Protected View mode, when user previews a Word attachment on Outlook

Side note: Attentive readers may note that it is a bit different from the Adobe Acrobat Reader scenario we previously discussed, the sandboxed “WINWORD.EXE” process is started directly via Outlook process, not via “prehost.exe”, and there is only one “WINWORD.EXE” process, while in the Adobe Acrobat Reader scenario, there are two “Acrobat.exe” processes.

III – The Advanced: the Email Reading and Special Object Attack Vectors

3.1 – The Email Reading Attack Vector

The Email Reading attack vector is for the scenario in which the security problem is triggered as long as the victim reads the (attacking) email on Outlook. So this is a very powerful attack vector.

It is often referred to as the “Preview Pane” attack vector in the security domain, especially for Microsoft Security Update pages. For example, the following is a vulnerability patched by Microsoft which could be triggered when users read emails on Outlook but is referred to as the “Preview Pane” attack vector.

Figure 13 – A typical Microsoft Security Update webpage where Microsoft describes a vulnerability that could be triggered by “Preview Pane”

It is, in fact, a confusing name, as someone pointed out also. Anyway, when we read that Microsoft claims the Outlook Preview Pane is an attack vector, we can assume that the vulnerability could be triggered as long as the user reads emails on Outlook.

This lies in the core functions where Outlook processes emails or other objects that are delivered together with emails. From a vulnerability research point of view, that usually occurs when there is a vulnerability when Outlook parses or processes the email format. Outlook supports three types of email formats: the plain text email format, the HTML email format, and the TNEF email format (commonly known as the “Outlook Rich Text” format). The HTML and TNEF are complex formats so they produce more vulnerabilities, especially for the TNEF which is (basically) a binary format. The bug types could vary from memory corruptions to logical bugs.

Protip: configuring your Outlook only to read plain text email is the best for security, although you may lose the usability, of course since these links, inline pictures will not show up in the plain text email.

The following figure is an example of a piece of a TNEF format email, note the string “Content-Type: application/ms-tnef”, which specifies this email follows the TNEF format.

Figure 14 – the content of a typical TNEF (Outlook Rich Text) format email

Historically, many vulnerabilities have been found in this Outlook Email Reading attack vector, but working exploits were rare. That is because finding a scripting environment within or triggered by Outlook is not an easy job but some slips still can happen. Here is an example.

In 2015, the author of this paper discovered and reported a logical bug in Outlook, dubbed “BadWinmail”, which allows running any Flash exploit (at that time, Flash was installed by default on Windows 8/10) embedded in the TNEF format, via the OLE mechanism. Arbitrary and reliable code execution is achieved as long as the victim reads the email on Outlook – no need to click anything, so it was a very powerful zero-day exploit. Here is the paper and video demonstration if readers would like to see the impact of such an attack vector.

3.2 – The Outlook Special Object Attack Vector

For the previous Outlook Preview Pane (Email Reading) attack vector, although it is already very powerful, the victim still needs to read the email. However, there is a possibility that the victim doesn’t even need to read the email at all,- for as long as the victim opens Outlook and receives emails from the email server, he/she could still be pwned. That’s the attack vector we call the ‘Special Object’ attack vector.

Here is a real-world example, in March 2023, Microsoft disclosed that they detected a threat actor using a zero-day vulnerability (CVE-2023-23397) in Outlook to attack Ukrainian organizations. The zero-day allows local Windows to leak (Net)NTLM credential information to the attacker-controlled server. In detail, the root cause is a logical vulnerability when Outlook processes the so-called “reminder” object sent from the attacker. Please note that this attack doesn’t even need the victim to read the email on Outlook – it would be triggered automatically as long as the victim opens Outlook and connects to the email server. Here is a good analysis including a video demonstration, from MDSec .

Comparing the User Interoperability Required for Each Scenario

Now that we have reviewed all the attack vectors on Outlook, it would be interesting and valuable to compare each of them to see how easy (or hard) the attack scenario could be used for delivering exploits. Our methodology has us assuming the position of the attacker and we already have a working exploit for the targeted application, but we need Outlook as a “delivering method” to “deliver” that exploit “into” the targeted application.

We could use scores to mark the user interoperability required (or, the difficulty of delivering the exploit) for the attack scenario. For example, assuming we have a zero-day exploit for Microsoft Access – an app is usually installed with Outlook as part of the Office suite – and we need to use Outlook to deliver that Access exploit. We tested that when Microsoft Access is installed in the victim’s machine, a .accdb attachment would fall in Scenario 2.1.2 – The attachment’s extension name is not marked as “unsafe” and not marked as “safe” either. As we previously examined, that would require 1 double-click and 1 single-click.

If we set the score of a single-click to 1.0, because performing one double-click is a bit harder than performing one single-click, we could set the score of performing one double-click to 1.2 (plus 0.2, compared to single-clicking). The harder performing the action, the higher the score.

Thus, for the above Scenario 2.1.2, the total score is 1.2 (one double-click) + 1.0 (one single-click) = 2.2.

With this methodology, we could have the following table.

ScenarioDescriptionUser interoperabilityScore1.1Web links in email body1 single-click1.01.2Other hyperlinks in email body1 single-click1.02.1.1Attachment opened in third-party app, file type marked as unsafeN/AN/A2.1.2Attachment opened in third-party app, file type not marked as safe nor unsafe1 double-click and 1 single-click2.22.1.3Attachment opened in third-party app, file type marked as safe1 double-click1.22.2.1Attachment previewed in Outlook, file type marked as unsafeN/AN/A2.2.2Attachment previewed in Outlook, no registered previewer for file typeN/AN/A2.2.3Attachment previewed in Outlook, has registered previewer but not marked as safe2 single-clicks2.02.2.4Attachment previewed in Outlook, has registered previewer and marked as safe1 single-click1.03.1Email Reading / Preview Pane attack vectorNo click, just reading email is enough0.23.2Other Outlook special object exploitationNo click, just receiving email is enough0

Table 1 – a scoring system for various attack scenarios on Outlook

As you can see, we set the score of the Email Reading / Preview Pane attack vector to 0.2 (Scenario 3.1), as it requires a little more user interoperability compared to Scenario 3.2 – special object exploitation. For the special object exploitation, we set the score to 0, as this is the perfect scenario for attackers.

As we can find in the table, the most challenging scenario for attackers is Scenario 2.1.2 – the attachment’s extension name is not marked as “unsafe” and not marked as “safe” either, which has the highest score – 2.2. The perfect one is the Scenario 3.2 – the Outlook special object exploitation (score 0), or the Scenario 3.1 – the email reading attack vector (score 0.2).

However, we need to take note that we are only comparing the user interoperability here; we have a big prerequisite of having a working exploit for the targeted app. In fact, most of the time, when the score is low (easy for exploit delivering), the difficulty of finding and developing a working exploit for the targeted app is high.

For example, for the web browser exploit, the score is low (1.0) which means it is relatively easy to deliver the exploit, but finding and developing a working exploit for modern browsers, such as Google Chrome, is costly (as the attacker needs to bypass all the modern exploitation mitigations). So from a defense point of view, the risks for web links in Outlook emails are not completely unacceptable for average users.

For another example, for Scenario 2.1.3 (one double-click to open the attachment), if we assume the attacker has a Word exploit that works on the normal mode but not the “Protected View” mode of Microsoft Word – it is, in fact, the most common case of Word-based attacks. If the attacker sends the exploit (from an external source) as an email attachment, in order to gain successful exploitation, the victim needs to not only perform the one double-click in this scenario but also needs to perform an additional single-click on Microsoft Word (for the “Enable Editing” button, see the following figure), in order to exit the very strict Protected View mode. So, there are in total two user-clicks required for delivering a typical Word-based exploit, if we consider the full attack chain.

Therefore, when we assess the risk for an exploit delivered via the Outlook attack vectors, we need to assess the whole picture – we need not just consider the Outlook attack scenario discussed in this paper, but also the exploit itself, including the difficulty of developing the exploit.

Conclusion

In this paper, we examined various attack vectors in modern Outlook and compared the user interoperability required for each scenario when attackers use Outlook to deliver their exploits. We analyzed the scenarios by acting as an average Outlook user, using real-world examples, and with our own cutting-edge vulnerability research efforts. We hope this paper can help the security industry deeply understand the security threats that Outlook may pose.

All discussed attack vectors in this paper are monitored and protected by Check Point solutions including Check Point Email Security & Collaboration Security. Harmony Email & Collaboration provides complete protection for Microsoft 365, Google Workspace and all your collaboration and file-sharing apps. Harmony Email & Collaboration is designed specifically for cloud email environments and is the ONLY solution that prevents, not just detects or responds to, threats from entering the inbox.

Harmony Endpoint provides comprehensive endpoint protection at the highest security level while XDR/XPR quickly identifies the most sophisticated attacks by correlating events across your entire security estate and combining with behavioral analytics, real time proprietary threat intelligence from Check Point Research and ThreatCloud AI, and third-party intelligence.

Threat Emulation as well as Check Point gateways provide superior security beyond any Next Generation Firewall (NGFW). Best designed for Zero Day protection, these gateways are the best at preventing the fifth generation of cyber attacks with more than 60 innovative security services.
Check Point Research proactively hunts Outlook and email related attacks in the wild. As a leading security company, Check Point continues to develop innovative detection and protection technologies for customers around the world.

The post The Obvious, the Normal, and the Advanced: A Comprehensive Analysis of Outlook Attack Vectors appeared first on Check Point Research.

Check Point Research – ​Read More

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

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.

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!…

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.

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

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