Login
This month brings us yet another critical RCE (Remote Code Execution) bug found in the RDP (Remote Desktop Protocol) Client which has also been ported to the Hyper-V Manager “Enhanced Session Mode” feature. User interaction is a prerequisite since the vulnerability lies within the RDP client, requiring a victim to connect to a malicious RDP server.
This RCE bug is very closely related to CVE-2021-34535 and to CVE-2020-1374 , where there is a heap-based buffer overflow in mstscax.dll due to an attacker-controlled payload size field. The vulnerability can be triggered via the RDP Smart Card Virtual Channel Extension feature [MS-RDPESC], by leveraging the existing local RDPDR static virtual channel setup between the client and server. The RDP Smart Card Virtual Channel Extension feature [MS-RDPESC] functionality was leveraged in the “EsteemAudit” Exploit released by the “Shadow Brokers,” but that vulnerability targeted the RDP server and not the client. The functionality being exploited here is the ability to share a smart card reader between the client and server. The destination buffer intended for the IOCTL (I/O control) call to locate each host smart card reader is a fixed size, but the user-controlled size field can be altered to cause the client to perform an OOB (Out of Bounds) write. Seeing how simple it is to trigger this vulnerability, our team decided to mutate the test case to verify whether any other IOCTLs within the [MS-RDPESC] specification are vulnerable. Enumerating through the 60 other IOCTL calls tied to the smart card reader, we were able to find two additional unique crashes. All vulnerabilities discovered have been patched in the latest version of the mstscax.dll, which shows that the fix for this bug has mitigated other potentially vulnerable functions. The patched mstscax.dll now simply verifies that the bytes received over the wire do not exceed the user-supplied size field; it does this at the IOCTL dispatch table level before any IOCTL functions are called, so the single validation is applied to all IOCTLs.
This vulnerability has a CVSS (Common Vulnerability Scoring Standard) score of 8.8, dropped down from 9.8 because it requires user interaction in that a victim RDP client must connect to a malicious server.
This bug has the same attack scenario as that of CVE-2021-34535, which we also analyzed in depth:
We have seen a regular cadence of critical RDP vulnerabilities since BlueKeep (CVE-2019-0708), but what distinguishes the two vulnerabilities CVE-2021-38666 and CVE-2021-34535 is that they impact Hyper-V Manager “Enhanced Session Mode” and can thus be leveraged for guest-to-host escapes. While we do not rate these vulnerabilities as critical in the same manner as past RDP server-side RCE vulnerabilities, we are now clearly starting to see a trend of vulnerabilities emerging which impact Hyper-V Manager due to the porting of RDP. We recommend patching as a top priority as threat actors will potentially look to weaponize this common protocol for guest-to-host escapes on Windows 10 Hyper-V.
Microsoft has published a Knowledge Base article for this issue here with information regarding patching this vulnerability. As always, we recommend patching as a first course of action and we will continue to monitor this vulnerability for any exploitation in the wild.
For RDP security best practices please see: https://www.mcafee.com/blogs/other-blogs/mcafee-labs/rdp-security-explained/
The post Windows RDP Client Porting Critical Vulnerabilities to Hyper-V Manager appeared first on McAfee Blog.
November 11 marks Veterans Day in the United States and Remembrance Day across Europe and beyond. Wherever you may be on this 11th day of the 11th month, on the 11th hour, please be thankful to all our Veterans for their service and sacrifice. We would like to take a moment to reflect and honor some of our McAfee Enterprise employees who served.
Shannon Clancy joined October 5, 2003 and was a Major in the United States Marine Corps
Kevin Benton enlisted ten days after high school (mid 1980’s) and was in the US Army as an E4/Specialist
Kevin Suares enlisted in the US Air Force on November 1, 1994, after four year’s he was a Senior Airman (E-4)
Clancy: I had always had a niggling in the back of my mind that I wanted to be a Marine (My father served as a Marine in Vietnam), and then September 11, 2001 happened and it solidified my choice. I wanted to be the best, and everyone knows Marines are the best.
Benton: The world was bigger than my little hometown and I wanted to travel the world. Plus, I was clearly the smartest person in my house at 18 years old, so I showed my parents how smart I was.
Suares: I needed money for college and needed some direction in life. Initially I considered the Navy, as I am a former Sea Scout. I spoke to a Navy recruiter and was ready to sign up. He sent me across the hall to “get a different perspective” from the Air Force recruiter (which I was also considering) and after a 20-minute conversation where we talked about options in the Air Force, Air Force training, how the Air Force encourages higher education and AF ethos, I changed my mind. Biggest regret of that Navy recruiter’s career! The next week I scored 97 out of 99 in the Armed Services Vocational Aptitude Battery (ASVAB) making me eligible for almost any job.
Clancy: I remember my first day being total chaos. Not knowing the (now) simplest things like how to wear your cover (hat), blouse your trousers, align your belt, etc. Things that seem small and silly but were in fact critical lessons in attention to detail that have carried with me throughout service and life.
Benton: On the first day, I was tired and nervous about not having any idea of what was happening or what to do. The last day was filled with wildly mixed emotions! I made some great friends from all walks of life, and I was ready to get on with my life by attending college on the GI Bill, but I hadn’t yet lived on my own. I recall driving off the base and wondering if I should drive north or south on the Pacific Coast Highway; ultimately, I drove North and have never regretted the decision.
Suares: I remember on my first full day being woken up at 4:30 AM after going to bed around 1:30 AM, in a new environment to a metal trash can being hit repeatedly with a baton and words I can’t repeat here. On my last day, my supervisor still made me work the whole day, ending in a small ceremony where I was presented with a few token gifts (which I still have.) I wrote my flight a quick email saying goodbye then left for home. Not going to lie – I had tears in my eyes as I left the building.
Clancy: My most memorable experience was my deployment to Iraq. There was a pause in operations on Thanksgiving and I got to play soccer with some of the Marines. It was a very “normal” thing in a place where there wasn’t much normal. I don’t miss much (because there is a lot of nonsense that also goes on), but what I do miss is the camaraderie and sense of belonging. You don’t question who you are or what your purpose is while you serve.
Benton: Being in the infantry, I recall experiencing some of the toughest, most physically demanding moments in my life, then experiencing shear exhaustion when reaching the end of a march or landing in a hot zone, only to have a few laughs with the guys to your left and right, toggling thru each other’s life stories. No one cared where you were from or the color of our skin or whether you had any money. I’ll never forget the laughs and storytelling as we were all experiencing the same things at the same time. Come to find out, we were forming bonds for life.
Suares: My most pleasant memory wastaking my grandfather out to dinner in uniform for his 70th birthday. He was so proud that he was speechless for once. If you knew him, that was a really big deal. But my saddest memory was hearing the rifle salute at a friend’s funeral. Each volley cut me to the bone.
Clancy: I usually call my dad. Veterans day buddies right up to the Marine Corps Birthday, so there is no shortage of celebrations or drinks to be shared among Marines. This year has been extremely difficult on veterans; so, I think I’ll text a few friends I haven’t heard from in a while. I encourage everyone to reach out to one you know, just to check in and say hi. It goes a lot further than you might think.
Benton: Our little town holds a ceremony at our local cemetery. I’ve attended with my family for years, afterwards nearly always telling my kids stories of my service to my country and the pride I feel when seeing our flag and all that it stands for.
Suares: Usually with service to others. Occasionally I may go out to dinner with family, but most times I used to be involved in giving talks to youth groups, schools, etc. or donating time to other Veterans causes. I proudly served my country – and would do it again if asked – but I feel that I am not owed anything. The day should be about recognizing the living service member (past or present) and honoring us all.
The post Veterans Day & Remembrance Day 2021 appeared first on McAfee Blog.
McAfee Enterprise and FireEye recently teamed to release their 2022 Threat Predictions. In this blog, we take a deeper dive into cloud security topics from these predictions focusing on the targeting of API services and apps exploitation of containers in 2022.
Recent statistics suggest that more than 80% of all internet traffic belongs to API-based services. It’s the type of increased usage that grabs the attention of threat developers hunting for rewarding targets.
Feature-rich APIs have moved from being just a middleware to applications and have evolved to become the backbone of most modern applications that we consume today. Examples include:
In most cases, attacks targeting APIs go undetected as they are generally considered as trusted paths and lack the same level of governance and security controls.
The following are some of the key risks that we see evolving in the future:
Gaining visibility into application usage with the ability to look at consumed APIs should be a priority for organizations, with the goal of ultimately having a risk-based inventory of accessed APIs and a governance policy to control access to such services. Having visibility of non-user-based entities within the infrastructure such as service accounts and application principles that integrate APIs with the wider enterprise eco-system is also critical.
For developers, developing an effective threat model for their APIs and having a Zero Trust access control mechanism should be a priority alongside effective security logging and telemetry for better incident response and detection of malicious misuse.
Containers have become the de facto platform of modern cloud applications. Organizations see benefits such as portability, efficiency and speed which can decrease time to deploy and manage applications that power innovation for the business. However, the accelerated use of containers increases the attack surface for an organization. Which techniques should you look out for, and which container risk groups will be targeted? Exploitation of public-facing applications (MITRE T1190) is a technique often used by APT and Ransomware groups. MITRE T1190 has become a common entry vector given that cyber criminals are often avid consumers of security news and are always on the lookout for a good exploit. There are numerous past examples in which vulnerabilities concerning remote access software, webservers, network edge equipment and firewalls have been used as an entry point.
The Cloud Security Alliance (CSA) identified multiple container risk groups including:
How do you protect yourself? Recommended mitigations include bringing security into the DevOps process through continuous posture assessment for misconfigurations, checks for integrity of images, and controlling administrative privileges. Use the Mitre ATT&CK Matrix for Containers to identify gaps in your cloud security architecture.
The post Cloud API Services, Apps and Containers Will Be Targeted in 2022 appeared first on McAfee Blog.
In life, regret tends to take on many shapes and forms. We often do not heed the guidance of the common anecdotes we hear throughout our days and years. From “look before you leap” to “an apple a day keeps the doctor away” – we take these sayings in stride, especially when we cannot necessarily provide proof of their veracity!
One particular trope that may incite ire, frustration, or regret when applied to enterprise security is – “once bitten, twice shy.”
In its very literal sense, we’re taught that if we’re bitten by something once – whether that be dog or security breach – we’re innately cautious or fearful of falling into a similar scenario. With dogs or any animal, we may pivot our behavior to avoid sharp teeth. However, with security breaches, many enterprises continue to be blindsided by “bites” – despite believing they’ve taken the utmost of caution to protect against them.
There is a clear disconnect between enterprise-preparedness and the severity of today’s threat landscape. We continue to see that no enterprise is immune to threats and breaches, with ransomware campaigns continuing to get more sophisticated and prevalent. We’re also seeing cyber criminals work together, banding as an enterprise themselves sharing common tools and knowledge. This means, as cyber criminals become more business-savvy, operational, and efficient – the enterprises they look to attack need to consistently be one step ahead to anticipate and prevent breaches.
The term digital transformation is not new by any means, but it needs to be newly approached through a security-first lens. For successful digital transformation to occur today, major industries need to focus on superior prevention against threats.
It’s time for business leaders to stop focusing on the “breach of the month” and more on building security into the fabric of their organizations so they’re not the next victims. For this to happen, it is imperative to break down silos of threat and information intelligence across the organization, enabling a collaborative, holistic, and strategic approach to securing the business.
Additionally, as we’re seeing more prevalent and sophisticated attacks, enterprises need to lean into the transformative technologies that can keep up with evolving techniques. AI provides for personalization of security – a key advantage as it can prioritize detection and response to allow organizations to focus on growth outcomes instead of spending time recouping lost data, customers, revenue, efficiencies, or more that can come at the expense of a threat or breach.
Placing security at the forefront of strategies can unleash the full potential of what digital transformation can make possible. With this approach and a mindset focused on prevention and cyber-readiness as the catalyst aiding true digital and business transformation, we have the power to turn the headlines around. It is time for enterprises to bite back, and the criminals to shy away.
The post Digital Transformation Needs to (Re)Start with Security appeared first on McAfee Blog.
In the October 2021 Threat Report, McAfee Enterprise ATR provides a global view of the top threats, especially those ransomware attacks that affected most countries and sectors in Q2 2021, especially in the Public Sector (Government).
In June 2021 the G7 economies urged countries that may harbor criminal ransomware groups to take accountability for tracking them down and disrupting their operations. Let’s review the high severity campaigns and threat profiles added to MVISION Insights recently.
Conti has been one of the top Ransomware groups in 2021, including a new campaign reported in September 2021. As mentioned earlier in this report, the public sector seems to be the sector most affected by Ransomware attacks. McAfee Enterprise provides regular publications on the strategies to defend against ransomware, such as this blog.
CVE-2021-40444 Microsoft MSHTML Remote Code Execution Vulnerability
This is a serious Microsoft Office vulnerability reported in September 2021 by Microsoft, McAfee Enterprise and other sources. The MVISION Insights heat map shows the prevalence of the Indicators of Compromise (IOCs) associated with this threat in the first half of October 2021.
Although Microsoft has provided guidance on a workaround, it can be challenging for many public sector organizations to deploy these patches quickly. To help you be more agile, McAfee Enterprise has released its own guidance leveraging ENS, EDR and NSP.
Microsoft Office vulnerabilities are commonly exploited in the early phases of the attack lifecycle. BazarLoader, mentioned earlier with the Conti Ransomware, has also been used with Word and Excel documents. In the MITRE Enterprise ATT&CK framework this technique is known as T1203, which we can find in 177 campaigns and threat profiles in MVISION Insights.
APT41 is a state sponsored threat group linked to China and associated with multiple campaigns, including a new campaign reported in September 2021. Although Ransomware is currently the main cyber threat type which hits the news, state sponsored threat groups are equally concerning, especially in the public sector for organizations with sensitive government and citizen data, which could be potentially exploited by a foreign nation like China.
In the second part of this report, we highlight how you can leverage the data from MVISION Insights to find traces of these attacks to enhance your level of protection.
In the October 2021 Threat Report, McAfee Enterprise ATR also assessed the prevalence of Cloud Threats, identifying the US Government sector as one of the top 10 verticals affected.
Many governments are moving quickly to adopt cloud technologies to bring services for their citizens, for collaboration and cost savings.
Inadequate readiness to address cloud security has been the primary contributor of these threats. Several cloud-native controls exist to protect sensitive data from loss or theft in real time, such as:
In the second part of this report, we want to give you some guidance on how you can operationalize this threat intelligence data to better protect your networks. MVISION Insights can help operationalize McAfee Enterprise Threat Intelligence data by providing risk assessment against threats affecting you, protective guidance and integrating with other tools to share threat data.
Let’s take the previous example of the Conti Ransomware Threat Profile. Below you can see how MVISION Insights provides:
1. A short description with the list of CVEs linked to this threat profile, the minimum version of McAfee Enterprise ENS AMcore content to be correctly protected against this threat, detections in your environment and on which device.
2. The list of related campaigns, the devices with unresolved detections related to these campaigns or those with insufficient protections.
3. The list of MITRE techniques and tools, which provide a universal and agnostic overlay of the threats, as well as details on the observables specific to this threat profile for each MITRE technique.
4. The list of IOCs with filters, IOC attributes, and IOC export features which you can use to share them with your other solutions, such as your SIEM, and which you can also share with other public sector entities. We also provide a direct integration with MVISION EDR. Alternatively, you can leverage the APIs to automate the exchange of IOCs.
If you find devices with these IOCs in MVISION EDR you can take immediate remote actions such as quarantine the device, kill the process, remove the files, or run custom scripts.
You can also use MVISION EDR for more advanced threat hunting such as searching for specific MITRE techniques in all MVISION EDR alerts …
… or in the MVISION EDR monitoring view which automatically groups the alerts.
5. MVISION Insights also provides hunting rules created by McAfee Enterprise Threat Intelligence experts using Yara, Sigma and McAfee Enterprise ENS expert rules.
6. A proactive assessment of your Endpoint and Cloud security posture score with guidance on the configuration changes which you should follow to ensure that your McAfee Enterprise Endpoint and Cloud solutions are protecting you with their full capabilities.
7. And all this, with more than 1,200 threat campaigns and threat profiles
MVISION APIs give you the ability to integrate and to exchange this extensive Threat Intelligence data with your SOC tools, including Threat Intelligence Platforms (TIPs) and Security Orchestration Automation and Response (SOAR).
These integrations can be used both in Internet-facing and closed networks. For advanced Threat Intelligence teams, our Advanced Program Group (APG) provides “Threat Intelligence as a Service” (INTAAS) including:
To conclude, here is a summary of the use cases you can achieve with MVISION Insights in the public sector:
If you want to learn more on our Threat Intelligence capabilities and participate in Architecture or Incident Response Workshops, contact your local McAfee Enterprise representative.
The post Ransomware Threats Affecting the Public Sector appeared first on McAfee Blog.
The time to repurpose vulnerabilities into working exploits will be measured in hours and there’s nothing you can do about it… except patch
By Fred House
2021 is already being touted as one of the worst years on record with respect to the volume of zero-day vulnerabilities exploited in the wild. Some cite this as evidence of better detection by the industry while others credit improved disclosure by victims. Others will simply conclude that as the “upside” grows (e.g., REvil demanding $70M or Zerodium paying $2.5M for exploits) so too will the quantity and quality of players. But the scope of these exploitations, the diversity of targeted applications, and ultimately the consequences to organizations were notable as well. As we look to 2022, we expect these factors to drive an increase in the speed at which organizations respond.
If we look back at the past 12 months, we have seen notable breaches that highlight the need for organizations to improve response times:
ProxyLogon. When we first learned in 2020 that roughly 17,000 SolarWinds customers were affected, many reacted in shock at the pure scope of the compromise (it should be noted that a small subset of these customers are believed to have been compromised by follow-on activity). Unfortunately, 2021 brought its own notable increase in volume. Two weeks after Microsoft released a patch for ProxyLogon they reported that 30K Exchange servers were still vulnerable (less conservative estimates had the number at 60K).
ProxyShell. ProxyShell, a collection of three separate vulnerabilities (CVE-2021-31207, CVE-2021-34473 and CVE-2021-34523), was Exchange’s second major event of the year after ProxyLogon. In August, a Black Hat presentation outlining Exchange Server vulnerabilities was followed the next day by the release of an exploit POC, all of which had been patched by Microsoft months earlier in April/May. This analysis of data captured by Shodan one week after the exploit POC was released concluded that over 30K Exchange servers were still vulnerable, noting that the data may have underrepresented the full scope (i.e., Shodan hadn’t had time to scan the full Internet). In summary: patched in the Spring, exploited in the Fall. So, what happened in the interim you ask? The vulnerabilities in the Microsoft Client Access Service were exploited by threat actors who deployed web shells to execute arbitrary code on compromised mobile devices and web browsers.
vCenter Server. Another notable example occurred in May when VMWare released a patch for a remote code execution vulnerability in vCenter Server. This subsequent analysis concluded that over 4,000 systems remained vulnerable one week after the patch was released. Much like Exchange servers, where a typical company will only host a handful of servers, 4,000 vulnerable vCenter servers likely represents thousands of distinct companies.
Kaseya VSA. One bright spot may in fact be the Kaseya VSA breach. On July 2, REvil launched an unprecedented (anyone else tired of that word?) ransomware campaign against public facing VSA servers. Within two days the DIVD CSIRT reported that the number of exposed VSA servers had dropped from 2,200 to 140. Some estimates suggested that around 50 MSPs were compromised, affecting between 800 and 1500 business. While this doesn’t sound like much of a bright spot, patching 94% of the affected systems in two days surely helped reduce the success of REvil copycats.
So, what can we take away from all of this? Well, attackers and security researchers alike will continue to hone their craft until weaponized exploits and POCs are expected within hours of vulnerability disclosure. In turn however, and largely driven by the increased consequences of compromise, we can also expect renewed diligence around asset and patch management. From identifying public facing assets to quickly deploying patches despite potential business disruption, companies will have a renewed focus on reducing their “time to patch.”
Still not convinced? Well, the US government is. Checkout Binding Operational Directive 22-01 published on November 3rd which compels all federal agencies to remediate known exploited vulnerabilities in two weeks or sooner “in the case of grave risk to the Federal Enterprise”. It’s no coincidence that CISA’s known exploited vulnerabilities catalog, which catalogues the vulnerabilities that must be remediated, includes every one of our examples above with a two-week remediation deadline. If the US government can do it, you can too!
The post Zero Care About Zero Days appeared first on McAfee Blog.
On November 17, 2021, The US Cybersecurity & Infrastructure Security Agency (CISA) pushed an Alert entitled “Iranian Government-Sponsored APT Cyber Actors Exploiting Microsoft Exchange and Fortinet Vulnerabilities in Furtherance of Malicious Activities” which you need to pay attention to if you use Microsoft Exchange or Fortinet appliances. It highlights one Microsoft Exchange CVE (Common Vulnerability & Exposure), three Fortinet CVEs and a list of malicious and legitimate tools associated with this activity.
A few hours later our Advanced Threat Research (ATR) team published a new campaign in MVISION Insights under the name “Cyber Actors Exploiting Microsoft Exchange and Fortinet Vulnerabilities”. Immediately after, MVISION Insights started to provide near real-time statistics on the prevalence of the tools associated to this threat campaign by country and by sector.
Figure 1. MVISION Insights Global prevalence statistics for this campaign on Nov 19, 2021
In this blog I want to show you how you can operationalize the data linked to this alert in MVISION Insights together with your investigation and protection capabilities to better protect your organization against this threat.
MVISION Insights combines Campaigns and Threat Profiles in the same list, and you can change the order from “Last Detected” to “Last Added” as shown below.
Figure 2. List of MVISION Insights campaigns last added, with a selection of this campaign
On the left of figure 2, a color code shows you the severity assigned by the McAfee ATR team (Medium for this campaign), in the middle you can see whether we have seen detections of the analysed IOCs in your country or in your sector
If you are a McAfee Endpoint Security or IPS customer, on the right of figure 2 you can see whether you have had any detection of these IOCs by your McAfee Endpoint Security or IPS, or whether Endpoint Security has found exposed devices, or devices with insufficient Endpoint Security protection
As shown in figure 2, you can also click the campaign’s preview to read a short description, and the labels given by MVISION Insights:
In this case, you can see that CISA suspects this campaign to be associated with an APT threat group. It includes Ransomware behaviors. The labels also highlight the use of hacking tools and vulnerabilities which you can then view in the Campaign details. Last September we hosted a webinar focused on threat intelligence and protection against hacking tools.
The campaign description highlights the usual use of “devices encrypted with the Microsoft Windows BitLocker encryption feature”.
The campaign’s details also provide links to other sources, such as the CISA alert in this case.
Figure 3. Original CISA Alert used for this campaign
Once you have identified campaigns which could potentially hit you, you can evaluate your risk and whether you could be exposed because you could have:
Figure 4. List of Common Vulnerabilities and Exposures (CVEs) in this campaign’s details
If you are a McAfee Enterprise customer, the MVISION Insights Endpoint Security Posture checks whether you have enabled the necessary Endpoint Security features to have the best level of protection across your estate.
In the example below:
As seen previously, this lab environment has sufficient protection to detect the “Cyber Actors Exploiting Microsoft Exchange and Fortinet Vulnerabilities” campaign IOCs. However, to have full Endpoint protection, GTI, On-Access scan, Exploit Prevention, Real Protect and ATP must be enabled.
Figure 5. McAfee Endpoint Security Detection across all MVISION Insights campaigns
If you are a McAfee Endpoint Security or IPS customer, the detections related to the campaign’s IOCs are automatically mapped by MVISION Insights as shown in Figure 6.
Figure 6: McAfee Endpoint Security Detection across all MVISION Insights campaigns
You can also use your Endpoint Detection and Response (EDR) or SIEM solution to search for the presence of IOCs. As you can see below in Figure 7, we have categorized the IOCs, and in this instance:
If you are an MVISION EDR customer, you can automatically search for the presence of these IOCs across your estate from MVISION insights
Otherwise, you can export the IOCs and hunt them in your EDR, and SIEM, to examine the evidence of a potential compromise and escalate the case to a level2 or level3 analyst to run a full investigation.
Additionally, you can also use the MVISION APIs with a third-party Threat Intelligence Platform such as ThreatQ, ThreatConnect or MISP to orchestrate this threat hunting capability.
Figure 7: MVISION Insights IOCs for this campaign
You can also leverage the new Campaign Connections feature (Figure 8) to check whether these IOCs are also listed in other campaigns or threat profiles. Campaign collection uses graphs to connect all the MVISION campaigns, and threat profile data such as:
Figure 8: MVISION Insights Campaign connection using the IOCs of this campaign
Beyond the IOCs, your Threat Analysts can also leverage the MITRE Techniques and Tools related to this campaign and documented in MVISION Insights.
Figure 9: MITRE Techniques and Tools observed in MVISION Insights for this campaign
For example, here you could use MVISION EDR to look for the presence of:
Then you can quarantine suspected devices before running a full remediation. You can also check that your Endpoint Security solution has credential theft protection capabilities such as ENS credential theft protection.
If your organization hosts Microsoft Exchange or Fortinet appliances you will need to apply the recommended patching and upgrade recommendations. If you find indicators of compromise you might want to increase the priority of the tickets, asking the Fortinet and Microsoft Exchange administrators to fix these CVEs due to these suspicious activities.
To better assess your risk and exposure against this campaign you should review your current capabilities to:
McAfee Enterprise offers Threat Intelligence, and Security Operations workshops to provide customers with best practice recommendations on how to utilize their existing security controls to protect against adversarial and insider threats; please reach out if you would like to schedule a workshop with your organization.
The post McAfee Enterprise Defender Blog | CISA Alert: MS Exchange & Fortinet Vulnerabilities appeared first on McAfee Blog.
This month it was disclosed that a Microsoft vulnerability that allows for local privilege elevation, previously patched in the November 2021 Patch Tuesday, is still exploitable and was not patched correctly. Using this vulnerability, threat actors with limited access to a compromised device can easily elevate their privileges to help spread laterally within the network.
Figure 1. MITRE ATT&CK Matrix for Windows Zero-Day in MVISION Insights
The vulnerability affects all supported versions of Windows, including Windows 10, Windows 11, and Windows Server 2022. At the time of writing, Microsoft has not released any updates or out-of-band patches to resolve it.
CVE-2021-41379 – Microsoft Windows Installer Elevation of Privilege Vulnerability
Bleeping Computer: New Windows zero-day with public exploit lets you become an admin
Bleeping Computer: Malware now trying to exploit new Windows Installer zero-day
McAfee Enterprise Global Threat Intelligence is currently detecting all known proof of concept exploits for this zero-day vulnerability as malicious.
McAfee Enterprise Endpoint Security (ENS) is currently detecting exploitation attempts and will quarantine the tools utilized to exploit this vulnerability as shown below.
Figure 2. Story Graph summary of exploitation detection by McAfee Enterprise ENS shown in MVISION ePO
MVISION Endpoint Detection and Response (EDR) is currently alerting to the activity of this exploitation as malicious and will note the MITRE techniques and any suspicious indicators related to the exploit attempts.
Figure 3. Detection of zero-day exploitation activity and techniques in MVISION EDR
MVISION Insights will provide the current threat intelligence and known indicators for exploitation of this vulnerability. MVISION Insights will also alert to detections that have been observed, and systems that require additional attention, to prevent widespread infection. MVISION Insights will also include Hunting Rules and Campaign Connections for threat hunting and further intelligence gathering of the threat activity and adversary.
MVISION Insights Campaign: New Windows Zero-Day CVE-2021-41379 With Public Exploit Lets You Become an Admin
Figure 4. Global Prevalence of zero-day exploitation activity in MVISION Insights
Figure 5. Exploitation IOCs and Detections in MVISION Insights
McAfee Enterprise offers Threat Intelligence Briefings along with Cloud Security and Data Protection workshops to provide customers with best practice recommendations on how to utilize their existing security controls to protect against adversarial and insider threats; please reach out if you would like to schedule a workshop with your organization.
The post McAfee Enterprise Defender Blog | Windows Zero-Day – CVE-2021-41379 appeared first on McAfee Blog.
Relying on the kindness of strangers is not an ideal strategy for CISOs and CIOs. And yet that is the precise position where most find themselves today while trying to battle cybersecurity issues across their supply chain. While these supply chains have plenty of their own challenges, such as global disruptions of distribution, our recent research shows that it’s the cybersecurity problems that will long survive for the long term.
It’s not as though enterprises rely on their partners any more today than they did ten years ago. Their needs have not changed and are unlikely to change, except those rare instances where an enterprise will choose to manufacture their own supplies rather than rely on partners. Consider, for example, Costco creating its own gigantic chicken farm. Other than outlier examples like this, partner reliance is relatively stable.
What is changing with the supply chain is how much system access is being granted to these partners. They are getting access they didn’t always get and are getting far deeper access as well. As technology has advanced to allow such access, enterprises have accepted.
Given the wide range of partners–suppliers, distributors, contractors, outsourced sales, cloud platforms, geographical specialists, and sometimes your own largest customers–the cybersecurity complexities are growing by orders of magnitude. In addition, the more integrations that enterprises accept, the higher the level that their risk is. To be more precise, the risk doesn’t necessarily grow with the number of partners as much as the risk grows with the number of partners whose cybersecurity environments are less secure than the enterprise’s own environment.
To even begin to craft a cybersecurity strategy to manage partners and a global supply chain, the enterprise CISO needs to have a candid understanding of what their partners’ security level truly is. That is tricky, given that many of those partners themselves do not have a good sense of how secure or insecure they are.
One suggestion is to revise contracts to make it a requirement for all partners to maintain a security level equal to the enterprise customer. The contract must not only specify penalties for non-compliance–and those penalties must be sufficiently costly that it makes no sense for a partner to take that chance–but it must specify means to determine and re-verify that security level. Surprise inspections and the sharing of extensive log files would be a start.
Otherwise, even the strictest security environment such as Zero Trust may be unable to plug supply chain holes due to sloppier partner security practices. Let’s say that a large enterprise retailer is working with a large consumer goods manufacturer as a partner. A good environment will start with strict authentication, making sure that the user from the partner is really that authorized user. The enterprise environment must also watch the user throughout the session to make sure the user doesn’t do anything suspicious. But if the partner has been breached, malware could sneak in through the secure tunnel and, if it’s not caught by the enterprise, there’s a problem and now they can be breached.
This is not hypothetical. Since the beginning of the pandemic, our research found that a vast majority of global enterprises (81 percent) said that they are seeing far more attacks since the beginning of COVID-19.
Almost every business is dependent on the supply chain, making it a prime target for cybercriminals looking to cause disruption and breach wider networks. As the holiday season approaches, we are already seeing a spike in consumer and business activity across the supply chain, making it a prime target for cybercriminals looking to target essential and lucrative services.
Attackers are going to continue to leverage the global supply chain as an initial entry vector, accessing the network through a trusted connection, system, or user. The fact that these attacks exploit trusted channels makes them very difficult to prevent or detect. As organisations continue their digital transformation, including ever-more cloud services, managed services and endpoint modernization, the risks of supply chain threats will increase as its prevalence as a vector does so.
The post Fighting Supply Chain Threats Is Complicated appeared first on McAfee Blog.
CVE-2021-20322: Of all the words of mice and men, the saddest are, “it was DNS again.”
For all our newcomers, welcome to the Advanced Threat Research team’s monthly bug report – a digest of all the latest and greatest vulnerabilities from the last 30-ish days based on merits just a tad more nuanced than sorting NVD by “CVSS > 9.0.” Instead, we focus on qualitative and experience-based analysis, relying on over 100 years of combined industry experience within our team.
To those who are returning after having read last month’s issue, I would like to congratulate you for being a Bug Report fan before it was cool – which it now most assuredly is, thanks in no small part to a litany of fascinating vulnerabilities. We encourage our veterans to stick around as long as possible, so that a year from now you can complain about how we’re washed up and how much better our early editions were.
Palo Alto Networks (PAN) firewalls that use its GlobalProtect Portal VPN running PAN-OS versions older than 8.1.17 are vulnerable to a cutting-edge, state-of-the-art style of vulnerability known as a “stack-based buffer overflow.” Although the vulnerable code is normally not reachable, when combined with an HTTP smuggling vulnerability, CVE-2021-3064 can be used to gain remote code execution, a remote shell, and even access to sensitive configuration data according to Randori Attack Team researchers. Randori discovered the vulnerability over a year ago but chose not to disclose it to PAN until September of this year, using it as part of its “continuous and automated red team platform” during the interim – I suppose we should be thankful that PAN has claimed in its security advisory that no evidence of exploitation of this vuln has been discovered, despite its age.
Absence of “in-the-wild” exploitation aside, we should also be grateful that the number of people who should care is rapidly dwindling (an ever-present theme of 2021). Randori initially reported over 70,000 internet-accessible PAN firewalls running vulnerable versions of PAN-OS according to Shodan, which it later amended to 10,000. As of this writing, that number has fallen to around 7,000. Even so, 7,000 vulnerable firewalls mean an even larger number of vulnerable clients at risk of an over-the-internet attack vector requiring zero authentication. Those connecting to PAN firewalls running on VMs have even greater cause for concern as these lack ASLR, a factoid I have chosen to add to my ever-growing “why is that a thing” list, right next to the Ghostbusters remake.
We suggest an experiment: open the Shodan search linked above and note the total number of devices running a vulnerable version of PAN-OS. Next, call up whoever manages your firewall and demand they power it down immediately – use threats if you must. Check the Shodan scan again: has the number gone down? If so, it’s probably time to update. If you’re an Arch user and the prospect of updating terrifies you, Palo Alto has also indicated that its signatures for Unique Threat IDs 91820 and 91855 should block exploitation of CVE-2021-3064.
Be sure to stay up to date on the latest CVEs – our security bulletins are a great resource for finding product information for all kinds of critical vulnerabilities.
Researchers at the University of California, Riverside have discovered a flaw in the way the Linux kernel handles “ICMP fragment needed” and “ICMP redirect” errors, allowing an attacker to quickly learn the randomized port number assigned to a UDP socket. What this description fails to convey is the big picture impact of this vulnerability, which is its use as a side-channel for the now-prehistoric DNS cache poisoning attack, in which an off-path malicious actor ‘poisons’ a DNS resolver’s cache with a false record, mapping a known domain (google.com) to an IP address of their choosing (98.136.144.138). Truly nefarious.
To be frank, just about everyone should be at least raising an eyebrow at this one. Although the researchers have indicated in their whitepaper that this particular side-channel only affects about 13.85% of open resolvers on the internet, it’s important to note that various security services rely on proof of domain ownership, including even the issuing of certificates, making the impact tremendous. Users of popular DNS service Quad9 have particular cause for concern, as the paper claims it falls under the vulnerable 13.85%. Linux users should also be concerned, and not just because their drivers refuse to work – DNS software such as BIND, Unbound, and dnsmasq running on their platform of choice are also vulnerable.
This is where things get tricky. DNS extensions that were standardized over two decades ago, such as DNSSEC and DNS cookies, should successfully mitigate this and all other DNS cache poisoning attack side channels. The unfortunate reality is that these features see very limited adoption due to backwards-compatibility concerns. While we wait for these dinosaurs holding back progress to die out, the authors of the aforementioned whitepaper have suggested some alternative mitigations, including enabling the IP_PMTUDISC_OMIT socket option, introducing additional randomization to the structure of the DNS exception cache, and configuring DNS servers with a singular default gateway to outright reject ICMP redirects. Further details can be found in section 8.4 of their paper.
Unfortunately, not every vulnerability can be adequately addressed by network security products, and this vulnerability happens to be one of those cases. Your best bet is to follow the mitigations mentioned above and keep your servers up to date.
Blacksmith, a name referring to both the vulnerability and the fuzzer created to exercise it, is a new implementation of the Rowhammer DRAM hardware vulnerability from 2014. The crux of Rowhammer is the use of high frequency read operations to induce bit flips in neighboring regions of physical memory, which can lead to the crossing of any security barrier if the attacker can massage memory so that critical data is stored in a vulnerable physical page. Modern DRAM hardware uses a technology called Target Row Refresh (TRR) to prematurely refresh regions of physical memory targeted by common Rowhammer attacks. Researchers at ETH Zurich and their associates discovered that TRR exploits the uniform nature of memory accesses used by existing Rowhammer attacks to “catch” them, and so devised a Rowhammer attack that used non-uniform accesses, arriving at CVE-2021-42114, which bypasses TRR and all other modern Rowhammer mitigations.
Everyone. Just about every common electronic device you can think of uses DRAM and of the DIMMs (RAM sticks) tested, the researchers did not find a single one that was completely safe. It might be easy to presume that hardware vulnerabilities such as this are academically fascinating but have little real-world impact, but research published since 2014 has shown Rowhammer attacks successfully escape JavaScript containers in the browser, cross VM boundaries in the cloud, and even achieve RCE across networks with high enough throughput. Perhaps the greatest tragedy of Blacksmith is that it arrived a month too late – it would have fit in perfectly with Halloween monsters like Freddy Krueger or Jason Voorhees who also see new iterations every few years and refuse to stay dead.
Hide your PC, hide your tablet, and hide your phone, ‘cause they’re hammerin’ everybody out there. Beyond that, there’s not much to be done besides wait for JEDEC to develop a fix and for DRAM manufacturers to begin supplying hardware with the new standard.
We at McAfee Enterprise are doing everything in our power to address this critical vulnerability. In other words, we’ll be waiting for that JEDEC fix right along with you.
The post The Bug Report – November Edition appeared first on McAfee Blog.
On December 9th, a vulnerability (CVE-2021-44228) was released on Twitter along with a POC on Github for the Apache Log4J logging library. The bug was originally disclosed to Apache on November 24th by Chen Zhaojun of Alibaba Cloud Security Team. The impact of this vulnerability has the potential to be massive due to its effect on any product which has integrated the log4j library into its applications. This includes products from internet giants such as Apple iCloud, Steam, Samsung Cloud storage, but thousands of additional products and services will likely be vulnerable. This is just the beginning as Java is heavily used in applications spanning nearly every industry.
The vulnerability exists in the way the Java Naming and Directory Interface (JNDI) feature resolves variables. When a JNDI reference is being written to a log, JNDI will fetch all requirements to resolve the variable. To complete this process, it will download and execute any remote classes required. This applies to both server-side and client-side applications since the main requirements for the vulnerability are any attacker-controlled input field and this input being passed to the log.
To orchestrate this attack, an attacker can use several different JNDI lookups. The most popular lookup currently being seen in both PoCs and active exploitation is utilizing LDAP; however, other lookups such as RMI and DNS are also viable attack vectors. It’s worth noting that the simplistic LDAP/RMI attack vectors only work with older JDK versions. There are publications that have demonstrated methods to circumvent this limitation to achieve code execution, albeit with added complexity to the attack.
Java object deserialization vulnerabilities are not a new breed of vulnerabilities or attacks. Previous offensive research such as “marshalsec” can be applied to this vulnerability making code execution simplistic.
**Update 12/20/2021**
On December 18th, a new denial of service (DOS) vulnerability, CVE-2021-45105 was discovered affecting versions 2.0-alpha1 through 2.16.0 of Log4j. To mitigate the original Log4j vulnerability, Apache completely disabled JNDI lookups in version 2.16, however self-referential lookups remained a possibility under non-default configurations. When a nested variable is substituted by the StrSubstitutor class, it recursively calls the substitute() class. When this nested variable recursively references the variable being replaced, it leads to an infinite recursion and a DoS condition on the server. Current research shows this does not lead to code execution, like the previous vulnerabilities.
****
**Update 12/14/2021**
It has been confirmed that Log4j version 1.2 is vulnerable to similar attacks through the JMSAppender component and has been issued CVE-2021-4104. It is important to note this is not as easily exploitable as version 2.x. For exploitation to occur, JMSAppender must be enabled, and set with TopicBindingName or TopicConnectionFactoryBindingName configurations allowing JMSAppender to perform JNDI requests. This is not the default configuration.
****
**Update 12/20/2021**
Apache has released a new version of Log4j, version 2.17.0 to address the latest DOS vulnerability. Two additional classes were created that inherit from StrSubstitutor to deal with parsing strings that may contain user input. These additions do not allow recursive evaluation. Due to exploitation of this vulnerability leading to a DOS, it is considered less critical than the previously reported Log4j vulnerabilities which can lead to remote code execution. It is important to note, for exploitation to be successful there are several non-standard conditions that need to be met. As the Log4j situation is continuing to evolve, we recommend upgrading to version 2.17.0, where possible.
*****
**Update 12/14/2021**
Apache has released a new version of Log4j, version 2.16.0. This update disables JDNI by default requiring a user to explicitly turn the JNDI feature on and completely removes support for message lookups. When considering mitigations strategies for the Log4Shell vulnerabilities this should be considered the preferred method of mitigation.
****
There is a lot of information about different ways to mitigate this vulnerability. The most important and complete mitigation is to update log4j to the stable release version 2.17.0. Some sources are reporting that Java versions 6u211, 7u201, 8u191, and 11.0.1 are not vulnerable to this attack. This is not entirely the case. These versions are more resilient to the LDAP attack vector; however, they do not completely mitigate the vulnerability and are still susceptible to attack. To determine if a Java application is running a vulnerable version, a list of the impacted JAR files can be determined based on the hashes linked here.
The McAfee Enterprise ATR (Advanced Threat Research) team has been closely tracking this vulnerability since it became known. Our initial goal was to determine the ease of exploitation using the public PoC, which we have reproduced and confirmed. This was done using the public Docker container, and a client/server architecture leveraging both LDAP and RMI, along with marshalsec to exploit log4j version 2.14.1. We have posted a short video to demonstrate the reproduction for anyone who is struggling with this.
Going forward we plan to test variations of the exploit delivered using additional services such as DNS. We may update this document accordingly with results.
In the meantime, McAfee Enterprise has released a network signature KB95088 for customers leveraging NSP (Network Security Platform). The signature detects attempts to exploit CVE-2021-44228 over LDAP. This signature may be expanded to include other protocols or services, and additional signatures may be released to complement coverage.
Full coverage for this vulnerability can be tracked from our Security Bulletin here.
Resources for the issue continue to evolve and expand rapidly. A growing list of PoCs and tools can be found here:
https://github.com/tangxiaofeng7/apache-log4j-poc
https://github.com/christophetd/log4shell-vulnerable-app
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22
https://rules.emergingthreatspro.com/open/
https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes
https://github.com/corretto/hotpatch-for-apache-log4j2
https://github.com/nccgroup/log4j-jndi-be-gone
The post Log4Shell Vulnerability is the Coal in our Stocking for 2021 appeared first on McAfee Blog.
By Guilherme Venere, Ismael Valenzuela, Carlos Diaz, Cesar Vargas, Leandro Costantino, Juan Olle, Jose Luis Sanchez Martinez, AC3 Team
Collaborators: ATR Team (Steve Povolny, Douglas McKee, Mark Bereza), Frederick House (FireEye), Dileep Kumar Jallepalli (FireEye)
In this post we want to show how an endpoint solution with performant memory scanning capabilities can effectively detect active exploitation scenarios and complement network security capabilities your company has implemented.
As it is becoming the norm lately, a new vulnerability affecting a widely used library was recently released just in time for the Holidays. As detailed in our ATR blog, CVE-2021-44228 reported a vulnerability in the Log4J Java library affecting applications and web sites using the library to perform logging.
This vulnerability allows an attacker to coerce the vulnerable site or application to load and execute a malicious Java code from an untrusted remote location. Attack vectors are varied but the most common is associated with the attacker sending crafted strings as part of a network protocol to the target machine, like for example a modified HTTP Header sent as part of a POST request.
That is the reason many defenders are focusing their efforts on detecting the malicious strings through the network traffic. However, network signatures can be bypassed and there are reports confirming threat actors are adapting their network attacks with various forms of obfuscation to defeat network scanning. The following image shows some of the current obfuscation techniques that have been observed or reported related to this attack.
Source: https://github.com/mcb2Eexe/Log4j2-Obfucation
This doesn’t mean that network protection solutions are not useful against this attack. Network security platforms provide a first layer of defense and should be used as part of a defensible security architecture (security risk treatment strategy), augmented by additional layers of protection, detection, visibility, and response. Modern endpoint solutions are uniquely positioned to complement network-based capabilities with in-depth host-based visibility of system processes, like in-memory scanning and rapid response orchestration. This combination results in a robust defense against threats like Log4Shell.
To understand how memory scanning can help complement the network security platforms after a connection arrives to the endpoint and defeating the obfuscation layers, let’s take a look at the diagram below, describing the flow of execution for a common web based Log4J attack.
Let’s outline what happens:
In Step 1, an attacker sends a specially crafted string to the web server hosting the vulnerable application. This string, as we have seen, can be obfuscated to bypass network-based signatures.
In Step 2, the application proceeds to de-obfuscate this string to load it in memory. Once loaded into memory, the application initiates a LDAP connection to request the address of where the malicious class is located.
In Step 3, the attacker-controlled LDAP server responds with the location of the malicious Class file by indicating the HTTP URL address of where it is hosted.
In Step 4, the vulnerable application will proceed to initiate a download for that malicious class file.
In Step 5, the vulnerable application will load and run the malicious class file from step 4.
At this moment, the attacker achieves code execution on the target, leaving traces that may provide visibility on this activity for the defender. For example, spawning additional processes or touching files and registry keys after an exploitation
With this in mind, let’s imagine we could trigger a memory scan at some point in this execution flow to detect the presence of the malicious code. In general, scanning the memory of an endpoint is expensive from a processing perspective, therefore it’s not something that can be done continuously or even very often, but under specific circumstances it can be achieved with precision.
So, suppose we could trigger a memory scan at any point after step (2). We would have a high probability to find the de-obfuscated string used within the process memory at that time. If the memory is scanned after the malicious class file is downloaded, that content would also be available for scanning in its de-obfuscated form.
Such possibilities make the memory signature performant, and efficient, given the timing of the detection mainly depends on the trigger used to start the memory scan.
These technical capabilities are possible in ENS, let us show you how to do that!
In ENS (Endpoint Security) 10.7 update 4 and above, there is a powerful security feature available to every defender, and WE absolutely love it, which is the ability to trigger a memory scan from an Expert Rule.
We have talked about Expert Rules before, these are customizable access control rules which the end-user uses to detect suspicious activity not commonly seen by other scanners. McAfee Enterprise also provides community Expert Rules mapped to the MITRE ATT&CK Matrix through our public GitHub.
The feature we are interested in now is the ability to trigger a memory scan when an Expert Rule fires. That would allow us to target the applications vulnerable to Log4J and identify the moment they are being exploited.
Consider the following rule:
In the example rule above, we see a section defining ACTORS (inside the Process {…} section) and TARGETS (inside the Target {…} section). We define as actors any process that may be vulnerable to the Log4J exploit. In this case JAVA.EXE for standalone Java applications and TOMCAT?.EXE for Apache web-based applications. Either of these processes need to load both JAVA.DLL and JVM.DLL to ensure the Java runtime is active.
In the target section we add any potential payload of the attack. As Expert Rules are not focused on network traffic, we need to focus on the last step of the execution flow, which is when the payload is executed. Additional triggers like files or registry keys accessed can be added as more information about exploits become available. We may also have in this section any exclusion of valid behavior as shown in the example above with the “Exclude” on command line parameter. This exclusion is something customers can tailor to their environment to avoid false positives.
This expert rule will trigger when any ACTOR process spawns any of the TARGET payloads. If the rule were just that, one could see it would not be too effective in detecting the exploit and would probably cause many false positives.
But notice this line at the beginning of the rule:
This instruction tells ENS 10.7 to initiate a memory scan against the ACTOR process which caused the expert rule to trigger, and only that process. Now we have a reliable trigger for a performant memory scan, avoiding the performance issues of a blind memory scan, and it is done at a time very close to the initial exploitation attempt, which guarantees the de-obfuscated string will be in memory.
The second part of this solution is executed by the AV DAT Engine when it scans the memory of the process which triggered the Expert Rule. Once this string is found, a detection will occur on the affected process, and the action configured in the Expert Rule REACTION line will be applied. More information about available actions are described in KB95901 – McAfee Enterprise coverage for Apache Log4j CVE-2021-44228 Remote Code Execution. Note we recommend customers to use the REPORT action initially until they have sorted out what processes they need to monitor.
The first event highlighted above is the Expert Rule triggering for a suspicious process spawning from JAVA.EXE, and the second shows the AV DAT detection indicating the memory of that process had signatures of the exploit.
Note:
IF only the Expert Rule detection was present and NOT the JNDI/Log4J-Exploit event, it would indicate a program has executed children processes considered suspicious, and customers are advised to review the event and improve the Expert Rule accordingly.
However, IF, both the Expert Rule and JNDI/Log4j-Exploit events are triggered for the same program, we have confidently detected the presence of the process being exploited.
McAfee Enterprise provides more information about our current coverage for Log4J vulnerability in KB95901 – McAfee Enterprise coverage for Apache Log4j CVE-2021-44228 Remote Code Execution. This article contain links to download the Expert Rule and the associated EXTRA.DAT, as well as details on how to set up ePO to use them in your environment.
Customers who want to implement this solution are invited to review the instructions in the KB and associated documentation. It is highly recommended to review the Expert Rule and customize it to your environment.
To protect an environment against attacks like LOG4J, a layered strategy comprised of network security coupled by targeted endpoint memory scans allows defenders to effectively detect and prevent the attack execution flow against vulnerable systems exposed via network vectors.
Our ENS Expert Rules and Custom Scan reactions are designed to enable defenders with such capabilities so they can apply precise countermeasures against these emerging threats.
The post Log4J and The Memory That Knew Too Much appeared first on McAfee Blog.
Log4j/Log4shell is a remote code execution vulnerability (RCE) in Apache software allowing attackers unauthenticated access into the remote system. It is found in a heavily utilized java open-source logging framework known as log4j. The framework is widely used across millions of enterprise applications and therefore a lucrative target for threat actors to exploit. The availability of the POC exploit and ease of exploitation triggered the widespread exploitation attempts that we are now witnessing.
CVE-2021-44228 – Apache Releases Log4j Version 2.15.0 to Address Critical RCE Vulnerability Under Exploitation.
Should the vulnerability be present, an attacker might run arbitrary code by forcing the application or server to log a specific string. This string can force the vulnerable system to download and run a malicious script from the attacker-controlled system, which would allow them to effectively take over the vulnerable application or server.
A full technical analysis can be found here:
McAfee Advanced Threat Research: Log4Shell Vulnerability is the Coal in our Stocking for 2021
In this blog, we present an overview of how you can mitigate the risk of this vulnerability exploitation with McAfee Enterprise solutions. Due to the severity of this vulnerability and the observed exploitation attempts already taking place, the KB article linked below will be continually updated to communicate detailed actions to mitigate risk with McAfee Enterprise products. Subscribe to this KB article to receive updates pertaining to related coverage and countermeasures.
KB95091: McAfee Enterprise coverage for Apache Log4j CVE-2021-44228 Remote Code Execution
Organisations preparing to defend against this threat needs to think beyond the initial access vector. What the vulnerability allows a threat actor to do is initially only connect to a remote endpoint and establish a beachhead. The attacker only gets a return on investment when they can exploit that initial foothold either to move laterally, execute additional payloads on the endpoint or attack other organisations as part of a botnet. Instead of just focusing on the initial access vector, let’s look at the entire defensive kill chain.
The impact on organisations varies between resource takeover, denial of service or data theft. Therefore, making visibility in attack patterns and trend via threat intelligence extremely critical. In addition, other attack vectors have been discovered which allows for local exploitation of the log4j library over WebSocket.
Let’s walk through the defense lifecycle in more details
Threat Intelligence is critical to adapt security controls and gain an understanding of attacker techniques and active campaigns exploiting the vulnerability
The MVISION Insights platform reports threat intelligence related to the Log4j attacks under the campaign name Log4Shell – A Log4j Vulnerability – CVE-2021-44228.
The Global Prevalence map snapshots captured on the 10th and 16th December 2021 demonstrates how impactful has being the vulnerability so far and how fast activity, both defender and attack, is increasing and spreading worldwide.
MITRE Techniques Observed:
As we are writing this blog, on MVISION Insights there are 1,813 IOCs including MD5, SHA256, URL, IP, DOMAIN, HOSTNAME. In terms of Determinism, 1,632 are unique and 30 are commodity.
The top MD5 detected so far has been related to Kinsing (MD5: 648effa354b3cbaad87b45f48d59c616), a crypto miner with backdooring features. The file runs on Linux machines and has been uploaded on Virus Total for the first time in December 2020. Its detection increased by 161% between the 11th and the 15th of December 2021 and it is currently observed in 19 different countries. The log4j vulnerability is helping threat actors to push Kinsing malware via encoded payloads to vulnerable services exposed to the internet. And this is just the tip of the iceberg. We are actively monitoring for and analyzing new payloads.
The same unique indicator is also reported as part of other two threat campaign on MVISION Insights:
Since April 2020, when the Kinsing crypto miner was discovered, further developments of the malware have occurred including a rootkit component and other features that make detection harder. Kinsing comes with multiple shell scripts that download and install the backdoor, miner, and rootkit alter the system itself.
The IP address 45.155.205[.]233 included within the MVISION Insights IOCs and used by threat actor as a log4j callback attack server has been detected 6,884 times by December 4th topping 15,106 detections by December 7th. Most detected countries included the United States, Turkey, Thailand, UK, Taiwan, and Italy.
MVISION Insights also includes indicators related to unique variants of MIRAI botnet that McAfee observed being leveraged by threat actors to exploit the log4j vulnerability.
Shell scripts are using wget and curl tools for external communication as part of the attack chains analyzed.
Latest updates highlighted Conti ransomware group actively leveraging the Log4Shell exploit to gain access to internal corporate resources and lunch their malicious payloads. But also, Khonsari group and state sponsored APT35 have been reported by researchers.
In this case, you should detect and prioritise internet facing applications running java-based web servers such as Apache Tomcat, either isolate or patch these resources. Run vulnerability scans for both monolithic and containerized workloads to build an inventory of assets that might be impacted.
Continuously discovers your cloud resources and can run vulnerability scans for Virtual Machines and Containerized workloads in the cloud. MVISION Cloud has the ability to build an inventory of running processes within workloads as part of it application control capabilities. If log4j is used as a separate package we will detect the vulnerability in both runtime and container registry. If the log4j is included in the java binary we will not be able to scan it.
Ensure you run configuration audits for cloud assets that allow unrestricted outbound access and does not use firewalls or NAT GW’s for outbound connections. Run configuration audits for secondary misconfigurations that might allow the attacker to exploit IAM to elevate privileges, gain persistence or takeover other resources.
Compares the available defensive capabilities on the endpoint to the attacker techniques, tools and IOC’s and highlights exposed endpoints.
You can perform real time searches in MVISION EDR to identify endpoints with Log4j binaries.
The attacker only succeeds if they can get to this stage so blocking outbound suspicious connections, preventing execution of additional payloads, and protecting credentials/auth tokens theft are things that could prove to be critical in defeating the attack. As part of the available threat intelligence attackers are using several post exploit methodologies to pivot from the original log4j injection vulnerability. This varies from misuse of resources with crypto miners, deploying malware, or exfiltrating sensitive information.
Use Application Control (VM and Containers) to kill unverified server processes and payloads from executing.
OS Hardening (VM) – ensure that SE Linux state is enforcing
Use UCE URL filtering and Remote Browser Isolation to prevent browser-based exploit attempts over WebSocket and C2 attempts.
Use signature-based protection in ENS 10.7 to block known hashes of second stage malicious payloads. On December 12, 2021, McAfee Enterprise released V3 AMCore content 4648 (ENS) and V2 DAT 10196 (VSE). Generic detections are provided under the title Exploit-CVE-2021-44228.C.
In ENS (Endpoint Security) 10.7 update 4 and above, there is a powerful security feature available to every defender, which is the ability to trigger a memory scan from an Expert Rule. For more details on this capability, please see this blog post from our AC3 team
https://www.mcafee.com/blogs/enterprise/log4j-and-the-memory-that-knew-too-much
Additionally, it is recommended to enable the ENS ATP rules that prevent or detect post exploitation techniques such of second stage payload execution, credential dumping or encryption activity from ransomware, use of malicious tools or lateral movement.
An Emergency User Defined Signature has been written and tested by McAfee Enterprise to provide immediate protection against the Apache Log4j2 Remote Code Execution Vulnerability.
For details on latest signatures, please follow the KB…KB95091: McAfee Enterprise coverage for Apache Log4j CVE-2021-44228 Remote Code Execution
Assuming breach is critical especially if you know that you had exposed assets and therefore, build forensics and post exploitation detection techniques this includes exploitation of living of the land binaries (LOLBINS), credential dumping as well as using information such as known file hashes / hunting queries to query web server / reverse proxy/ Network IPS logs.
In addition to an Intelligence Summary, Insights provides exportable YARA rules to find additional Indicators of Compromise.
As mentioned above, you can leverage Real Time and Historical Search functionality to proactively identify vulnerable systems or post exploit activity such as…
Identify Indicators of Compromise associated with exploit payloads
Along with control on the endpoint, visibility into attacks and where data is being uploaded is also critical to stopping Data Exfiltration. Mapping threats to the MITRE ATT&CK Framework will provide visibility into ongoing attacks happening in the cloud and where security controls can be improved to stop future attacks.
Another critical method to stopping the exfiltration of data is putting restrictions against data uploads to non-sanctioned cloud storage. Limiting data uploads to only sanctioned Cloud Service Providers can stop external and insider threats from transferring data to Cloud Services that are questionable or not sanctioned. The Cloud Registry within MVISION Cloud/Unified Cloud Edge will provide ratings for well over 25,000 Cloud Service Providers so restrictions can be placed on CSPs with high risks or attributes that put company data at risk.
The current situation is dynamic and our resources to help you understand the attack and mitigations available are also evolving. For the latest updates on McAfee Enterprise threat intelligence and defender resources please continue to follow these sites
MCFE Log4Shell Vulnerability KB: https://kc.mcafee.com/corporate/index?page=content&id=KB95091
MCFE Log4Shell Security Bulletin: https://kc.mcafee.com/corporate/index?page=content&id=SB10377
MCFE Log4Shell Vulnerability Blog: https://www.mcafee.com/blogs/enterprise/mcafee-enterprise-atr/log4shell-vulnerability-is-the-coal-in-our-stocking-for-2021/
MCFE Log4Shell Exploit Demonstration by McAfee ATR: https://www.linkedin.com/posts/mcafeeenterprise_cve-2021-44228-log4shell-exploitation-activity-6876241150219485184-URLE
MCFE LinkedIn Live Customer Briefing: https://www.linkedin.com/posts/mcafeeenterprise_mcafee-enterprise-atr-explore-the-internet-breaking-activity-6876614287197122560-wNuD
FEYE Log4Shell Vulnerability KB: https://community.fireeye.com/s/article/000003827
The post Threat Intelligence and Protections Update Log4Shell CVE-2021-44228 appeared first on McAfee Blog.
If you’re reading these words, CONGRATULATIONS! You’ve made it to 2022! And even better, you found your way to ATR’s monthly security digest where we discuss our favorite vulnerabilities of the last 30 days. Feel free to pat yourself on the back, get yourself a nice cup of coffee, tea, LaCroix (you fancy!) or if you’d rather choose violence, you can go straight for the energy drink. And now that we are comfortable and energized, let’s get rolling!
Per its Wikipedia entry, Grafana is a multi-platform open-source analytics and interactive visualization web application that is widely used in the industry, with paying customers such as Bloomberg, eBay, PayPal, etc. It was revealed in early December that a path traversal vulnerability allowed an attacker to access local files due to an improper sanitization of “../../../” in its plugin path.
It also showcases one of the tightest disclosure timelines known to man:
Ok, we can hardly blame you for hearing about ANY vulnerabilities except for Log4Shell in the last 30 days. However, if your organization is using this software, you probably should have followed the disclosure last month, lest your “/etc/passwd” files are now known to the whole internet. Beyond that, there are two interesting points you can ponder while swirling your eggnog in its glass (side-rant on the disgustingness of eggnog redacted). Given how easy it is to exploit, the mere fact of the vendor fixing the bug via their public GitHub seems to have been enough to bring attention to it and get public working POCs for this vulnerability in less than 3 days following the fix. If you’re curious about how more mature open-source code bases deal with this risk, projects like Chromium rely on a separate bug tracking infrastructure that can restrict who can access the bug reports (that will spell out the security risks and test cases) combined with public commit messages with simple phrasing meant to avoid attracting the attention on the security commits.
Another interesting tidbit, the root cause of this bug is the misuse of a Go API to sanitize paths as discussed in this Twitter thread. It turns out the filepath.Clean function used to sanitize the input processed by the vulnerable code only removes excessive “../../” if the path is absolute. This is a common case of an API behaving as expected but leading to dangerous consequences. Do you know for sure the codebase of your organization is free of these problems? The impact of unpatched vulnerabilities here could be the accessing or leaking of extremely sensitive data. *pondering becomes frantic*
Obviously update the software if you’re using it, and you can also use Sigma rules to detect attack attempts. In an ideal world, your analytics platform should not be exposed to the wide internet, unlike these 87k instances, among whose 16k are still vulnerable according to Shodan. At minimum make sure your Grafana instance is behind a .htaccess prompt or similar. From a development perspective, security testing and unit tests should be leveraged to ensure the filtering you are putting in place is working the way it is intended to. And in the grand scheme of things, if you are going to process untrusted user input, don’t wing the filtering and apply thoroughly audited code patterns rather than disabling the warnings of your security tool…
“Does the walker choose the path, or the path the walker?” may have mused Garth Nix in his novel Sabriel. One thing is certain though, the path described above won’t be “walked” nor traversed by an attacker for the McAfee Network Security Platform (NSP) customers. These lucky fellows are already protected against path traversal attacks via a generic rule and can even be bestowed further protection with the creation of “custom attack” rules.
Who could have known that parsing—and sometimes even executing—untrusted input was a bad idea? Well it turns out that Apache’s log4j logging code does exactly that, and if the logged string contains the magic characters $(jdni:…) it may even fetch and execute untrusted Java code. Iterations on this attack have also highlighted the possibility to leak local secrets stored in environment variables—such as AWS keys—and given the recursiveness of the processing, it also offers many ways to evade pattern-matching detection.
Pretty much everyone. You write Java and are into logging things? Yep, you should be on top of this. You use Java based applications/servlets? Well, there’s probably some logging of untrusted user input in there. Your corporate employer uses Java based appliances or services? Pour one for your SOC and IT folks who are probably having a blast over their holiday “break”. You get it, this problem impacts the whole industry, and in all likelihood, its effects will probably keep rippling out for the years to come. To make things worse, the bug is really easy to exploit. From pen testers to SOC analysts, “script-kiddies” to nation state actors, nearly everyone has begun to explore this attack vector and we have observed massive on-going attacks with a wide gamut of payloads, ranging from cryptominers to “rm -rf /*” payloads and even a broken attempt to spread the Mirai worm. The worst is likely yet to come.
“Stranger Things” taught us that “You can’t spell America without Erica.” Similarly, you can’t spell Apache without Patch. Sort of. Upgrade! Micro-patch. Monitor traffic. Hint: if you’re internal-only application suddenly makes LDAP requests towards a remote server in a country you have no operations in, maybe something fishy is going on…
If you like chaos and and/or you are having a hard time convincing IT of the importance of this bug, get permission to demonstrate it for them! Then, set strings you can control (user-agent, twitter name, wifi SSID, …) to this $(jdni:ldap…) magic value and make it point to an IP:Port you control (or a third party service like Canarytoken if you trust them). If you detect hits on that address, you can start having a fun conversation about the necessity of upgrading their tech stack with the owners of the incoming addresses. This is where asking for permission first becomes extremely important, as if you indiscriminately put the magic string all over the places to see what happens (as you may have seen on various social media platforms), it’s likely that eventually someone will reach out to have a “fun” conversation with you and ask about that funky user-agent of yours. Obviously, before pulling a stunt like this consider that the last thing you want for Christmas is a CFAA (Computer Fraud and Abuse Act) complaint delivered right to your doorstep.
McAfee Enterprise customers are protected from many different angles (for the specifics, please visit this Knowledge Base article):
Big Sig sounds like the nickname Freud’s mother gave him. This bug is no less compelling. Early this December, Google Project Zero blogged about a vulnerability they found in Mozilla’s Network Security Services (NSS) with a CVSS score of 9.8, according to NIST’s National vulnerability database page. There is a heap overflow in the processing of certain signatures (DER-encoded DSA and RSA-PSS signatures). To put it simply, the NSS is a collection of cryptographic libraries that enable developers to use safer/heavily tested implementations of cryptographic primitives and standards (for encryption of communication, verification of the authenticity of data, and so on). The feature where the bug was found is responsible for the verification of signatures that prove the authenticity of data using various public cryptography schemes. This type of function is typically used to sign emails or documents to confirm their actual authors. Something really interesting about this bug is its relative simplicity but also its long existence; according to Project Zero’s blog, this bug was exploitable going all the back to 2012. The vulnerable code path just happened to fall between the cracks where various fuzzers used by Mozilla overlap.
If you like your signatures to be verified, and rely on the NSS library to do so, you should definitely have a look at the advisory and use the latest version of the software (NSS version 3.73/3.681 ESR or later). Firefox seems unaffected, but other software that parses signatures might be impacted (Thunderbird, LibreOffice, Evolution, Evince and more).
As usual, you want to make sure any software you are using that might be vulnerable is updated to its latest version. The patch was released on December 1st so, for starters, you’d want to make sure potential vulnerable software received an update after this date. It would also help to know which software relies on this library; while there is no magic bullet, references to files such as nss3.dll on Windows or libnss3.so on Linux are a good starting point. Beyond that, the best call is to look at release notes and potential list of third-party libraries used in any given application you may use. If you use the vulnerable library in in your own product, update the code or backport the patch.
Have you checked out our bulletins? They’re a great source of information for the critical vulnerabilities you may have missed! This may include applications that will be deploying fixes for CVE-2021-43527.
The post The Bug Report – December 2021 appeared first on McAfee Blog.
In February 2021, the company Dbappsecurity discovered a sample in the wild that exploited a zero-day vulnerability on Windows 10 x64.
The vulnerability, CVE-2021-1732, is a win32k window object type confusion leading to an OOB (out-of-bounds) write which can be used to create arbitrary memory read and write capabilities within the Windows kernel (local Elevation of Privilege (EoP)). Memory exploitation generally requires a read, write, and execute primitive to bypass modern exploit mitigations such as DEP, ASLR and CFG on hardened operating systems such as Windows 10. A data-only attack requires only a read and write primitive as it does not seek to execute malicious code in memory, but rather manipulates data structures used by the operating system to its advantage (i.e., to achieve elevated privileges).
Kernel exploits are usually the most sophisticated attack as they interact directly with the Windows kernel. When such attacks are successful, they are critical because they provide high privileges to the attacker, which can be used to increase the impact of the overall exploit chain. In this case the exploit is a Local Privilege Escalation (LPE) that targets 64-bit Windows 10 version 1909. The original sample discovered was compiled in May 2020 and reported to Microsoft in December 2020. While searching for additional findings we went through a public exploit published in March of 2021 by a researcher. Having this code publicly available may raise the potential for additional threat attackers. While we have not found clear evidence demonstrating malicious use of the proof-of-concept (POC), we did discover some variants being tested and uploaded to VirusTotal.
In this blog post, McAfee Advanced Threat Research (ATR) performed a deep dive into the analysis of the vulnerability, to identify the primitives for detection and protection. The exploit is novel in its use of a new win32k arbitrary kernel memory read primitive using the GetMenuBarInfo API, which to the best of our knowledge had not been previously known publicly.
Exploitation of CVE-2021-1732 can be divided into six stages with the end goal of escalating a process’ privileges to System. The following diagram shows the stages.
Before we dive into the details, we must give some background to win32k exploitation primitives which are used in the exploitation of CVE-2021-1732.
Win32k is a Graphical (GUI) component of the Microsoft Windows Subsystem, most of which exists in the kernel for performance reasons. It is used for graphical print of the Windows OS desktop. However, due to the win32k architecture, the kernel component of win32k still needs to be able to make calls to user mode through user-mode callback functions to facilitate window creation and management.
Kernel user-mode callbacks have been well researched as far back as 2008 and 2010, with a very comprehensive analysis in 2011 by Mandt. A win32k kernel function such as xxxCreateWindowEx will make a callback function such as xxxClientAllocWindowClassExtraBytes through the user process PEB KernelCallbackTable.
When the user-mode callback has completed, NtCallbackReturn executes and passes the expected return parameter back to the kernel. Due to the stateless nature of these callbacks, many vulnerabilities have been discovered related to the locking mechanisms on the objects leading to use-after-free (UAF) exploitation.
Win32k has been one of the most exploited components in the Windows kernel accounting for 63% of vulnerabilities from 2010 to 2018, due to its large attack surface of syscalls relative to ntdll syscalls. Win32k vulnerabilities are generally turned into data-only attacks using a read/write kernel primitive by using a desktop object known as a tagWND data structure.
There are two aspects to data-only attacks:
The tagWND data structure has two fields which make it a prime target for reading/writing within kernel memory; tagWND.cbWndExtra and tagWND.ExtraBytes. When a window is created using CreateWindowEx, it is possible to request additional bytes of memory directly after the tagWND object in memory through the cbWndExtra field in the WNDCLASSEXA structure when registering the window class.
The number of extra bytes is controlled by the cbWndExtra field, and the allocated additional memory address is located at the ExtraBytes field. The read/write primitive is created as follows:
Win32k kernel user-mode callbacks have been exploited many times by leveraging tagWND read/write capabilities within the Windows kernel for escalation of privileges such as CVE-2014-4113, CVE-2015-0057, MS15-061, CVE-2016-7255 and CVE-2019-0808.
Several primitives have been observed in the CVE-2021-1732 exploit used by the attackers; additionally, it is worth mentioning that some of them are new and not previously seen in the wild.
Prior to Windows RS4 it was trivial to leak tagWND kernel addresses using multiple techniques, such as calling HMValidateHandle to copy tagWND objects from the kernel to user desktop heap. The latest version of Windows 10 has been hardened against such trivial techniques.
However, using the spmenu kernel address leak technique and relative tagWND desktop heap offsets, once a vulnerability is discovered to overwrite a tagWND.cbWndExtra field, it is possible to achieve kernel read/write capabilities without leaking the actual tagWND kernel addresses. The spmenu technique in this exploit was used here and here, but we are not aware of the GetMenuBarInfo API ever being used before in a win32k exploit.
The following diagram shows the primitives used in CVE-2021-1732.
Great work has been done to harden the security of win32k against EoP attacks with new and improved mitigations by the Microsoft OSR team, Mandt, Google Project Zero, Schenk and Dabah. These mitigations include:
In the context of a malicious process exploiting CVE-2021-1732, the above mitigations provide no protection. However, it does not impact Google Chrome as it disallows win32k calls (Windows 8 and higher), or Microsoft Edge as it applies win32k filtering on the relevant APIs.
When a window is created using CreateWindowEx API, a tagWND object is created by the Windows operating system. This window, as explained above, can be created with a parameter to allocate extra memory using cbWndExtra.
During the windows creation process (CreateWindowEx API) a callback named xxxClientAllocWindowClassExtraBytes is triggered to allocate space in the user mode desktop heap for the tagWND.ExtraBytes (offset 0x128) per the tagWND.cbWndExtra (offset 0xc8) value size (see figure 3 and 4 below for WND1).
The location of this memory is stored as a user mode memory pointer to the desktop heap and placed at tagWND.ExtraBytes. It is then possible to convert the normal window to a console window using NtUserConsoleControl which will convert that user mode pointer at tagWND.ExtraBytes to an offset value which points into the kernel desktop heap (see figure 5 below for WND0). It is this change in value at tagWND.ExtraBytes (window type confusion) that can be exploited for an OOB write during the xxxClientAllocWindowClassExtraBytes callback window.
Per figure 6 above the following steps are required to trigger the vulnerability:
5. WND0 is then converted to a console window by calling NtUserConsoleControl which converts WND0.ExtraBytes from a user desktop heap pointer to an offset within the kernel desktop heap. This is needed later so that WND0 can write OOB to WND1.
6. Create malicious window WND_Malicious using the CreateWindowEx API
The vulnerability lies in the fact that win32kfull!xxxCreateWindowEx does not check whether the window type has changed between the time it initiates the xxxClientAllocWindowClassExtraBytes and gets the response from NtCallbackReturn.
When we call NtUserConsoleControl with WND_Malicious in the hook above, xxxConsoleControl checks if tagWND+0xE8 flag has been set to 0x800 to indicate a console window per figure below. As WND_Malicious was created as a normal window, xxxConsoleControl allocates memory at an offset within the kernel desktop heap and then frees the user desktop heap pointer existing at WND_Malicious.ExtraBytes (0ffset 0x128). It then places the offset to this new allocation in the kernel heap at WND_Malicious.ExtraBytes (0ffset 0x128) and sets the tagWND+0xE8 flag to 0x800 to indicate it’s a console window.
After returning from the callback when we issued NtCallbackReturn above, xxxCreateWindowEx does not check that the window type has changed and places the WND0+0x08 at WND_Malicious.ExtraBytes per figure 9 below. The RedirectFieldpExtraBytes checks the WND_Malicious.ExtraBytes initialized value but it is too late as WND0+0x08 has already been written to WND_Malicious.ExtraBytes (offset 0x128).
The patched win32kfull.sys has updated xxxCreateWindowEx to now check the ExtraBytes initialized value before writing the returned value from user mode to tagWND. ExtraBytes (offset 0x128) per figure 10 below.
Figure 11 below shows that tagWND. ExtraBytes is initialized to zero within xxxCreateWindowEx during normal window creation.
Figure 12 below shows that tagWND. ExtraBytes is initialized to the new offset value in the kernel desktop heap within xxxConsoleControl during console window creation. RedirectFieldpExtraBytes simply checks this initialized value to determine if the window type has changed. In addition, Microsoft have also added telemetry for detecting changes to the window type flag in the patched version.
The vulnerability within the xxxCreateWindowEx API allowed the WND_Malicious.ExtraBytes field be to set to a value of WND0 offset within the kernel desktop heap. Now any time SetWindowLongW is called on WND_Malicious it will write to WND0. By supplying an offset of 0xc8, the function will overwrite the WND0.cbWndExtra field to a large value of 0XFFFFFFF per figures 13 and 14 below.
This means it can write beyond its tagWND structure and ExtraBytes in kernel memory to fields within WND1. In addition, WND0.ExtraBytes is also overwritten with the offset to itself so calls to SetWindowLongPtrA on WND0 will write to an offset in kernel desktop heap relative to the start of WND0.
Now that the WND0.cbWndExtra field has been set to a very large value (0xFFFFFFF), anytime SetWindowLongPtrA is called on WND0 it will write into the adjacent WND1 in kernel memory per figure 15 below. By writing to specific fields in WND1 we can create a kernel address memory leak as follows:
Using the spmenu data structure kernel pointer leaked previously we can use the layout of this data structure and the GetMenuBarInfo API logic to turn it into an arbitrary kernel memory read per figures 18,19 and 20 below.
As you can see from the xxxGetMenuBarInfo function in figures 21 and 22 below, by placing our leaked kernel address at the right location in our fake spmenu data structure we can create an arbitrary kernel memory read when calling GetMenuBarInfo.
An arbitrary kernel write primitive can be easily achieved now by writing our destination address to WND1.ExtraBytes field by calling SetWindowLongPtrA on WND0 which will write OOB to WND1 relative to the offset we specify per figure 23 below
In this case the offset is 0x128 which is ExtraBytes. Then simply calling SetWindowLongPtrA on WND1 will write a specified value at the address placed in the WND1.ExtraBytes field. The arbitrary write is achieved because WND1 is a normal window (has not been converted to a console window like WND0 and WND_Malicious) and so will write to whatever address we place in WND1.ExtraBytes.
The arbitrary kernel read and write primitives can be combined to perform a data-only attack to overwrite a malicious process EPROCESS token with that of PID 4 which is System for an escalation of privilege (EoP).
The original spmenu kernel address leaked previously has a pointer to WND1 at offset 0x50 per figures 24 and 25 below. Through multiple arbitrary reads using the GetMenuBarInfo on our fake spmenu data structure with this WND1 kernel address we can eventually read the PID 4 System EPROCESS token.
By placing the destination address (malicious process EPROCESS token) at WND1.ExtraBytes then the subsequent call to SetWindowLongPtrA will write the value (PID 4 – System EPROCESS token) to that address per figures 26 and 27 below.
The exploit then restores overwritten data structure values once the EoP is complete to prevent a BSOD (Blue Screen of Death).
In this report, we undertook a deep analysis of CVE-2021-1732 which is a Local Privilege Escalation on Windows 10. Windows kernel data-only attacks are difficult to defend against, as once a vulnerability is discovered they use legitimate and trusted code through specific APIs to manipulate data structures in kernel memory.
The win32k component has been hardened through great work by Microsoft against read/write primitives, but there are still opportunities for exploitation due to its large attack surface (syscalls and callbacks) and lack of win32k filtering on a process-wide basis. It would also be great to see a system wide win32k filtering policy capability within Windows 10.
Patching is always the best solution for vulnerabilities, but a strong defense strategy such as threat hunting is also required where patching may not be possible, and to detect variants of vulnerabilities/exploits being used by campaigns.
The post Technical Analysis of CVE-2021-1732 appeared first on McAfee Blog.
Find out how you can stretch your organization’s security budget amidst inflation and its economic impacts.
No one could have predicted the lasting effects of the pandemic on our economy. A strain has been put on the overall supply chain, causing the value of the dollar, or any other local currency, to not go as far as it once did. Consumers are experiencing skyrocketing energy, gas, and food prices, and businesses are facing delays in deliveries of goods and services to their customers.
According to the Consumer Price Index (CPI), the U.S. economy has seen an uptick as high as 8.5% over the past twelve months, which is the largest spike since the early 1980s. Ideally, the economy should be in a balance of about 2% inflation.
When inflation rates go up, there is a steady rise in costs, putting a heavy burden on individuals and businesses.
Even with the rise in inflation, the need for products and services are still there to keep organizations operational. Cybersecurity attacks do not fall under the radar with inflation. If anything, cost increases mean you might get less protection for the same amount of spend, making cyber threats against your organization riskier. Businesses are forced to make budget adjustments, but cybersecurity spend is crucial to maintain the integrity of customer data and finances. Many businesses will be forced to have to raise prices for goods and services, passing the higher cost on to their customers. The solutions needed to maintain security should be simple and flexible to buy in a complex world. Cisco believes in price protection, not passing on the burdens of inflation to our customer.
Cisco can help you with instant savings, avoiding inflation hikes with our price protection guarantee when it comes to buying security solutions to meet the security needs of your organization. With the significant shift in the way we work – remote work, office only, or hybrid, there are more devices on and off the network, leading to an increase in cybersecurity risks. Threats are not slowing down any time soon. Security needs to work together in a simple way to help you stay ahead of these threats to protect users everywhere, working from anywhere. Cisco Secure takes an integrated platform approach to radically simplify your security, applying intelligence to anticipate the changing needs of your business and provide the robust protection you need.
Whatever your organizational security needs may be, buying through the Cisco Secure Choice Enterprise Agreement allows you the flexibility to access two or more security products. Choose from network security, user & endpoint protection, cloud edge, or app security line of products.
Secure Choice Enterprise Agreements lets budgets go further and offers predictable billing over time so you can move faster in responding to security needs. Get a built-in security platform, SecureX, at no extra cost!
Cisco Secure products have never been simpler to buy. Add products, based on your specific security business goals, and receive additional discounts, up to 20% savings off list price. Start saving now with a Cisco Secure Enterprise Agreement.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
The 911 service as it exists today.
For the past seven years, an online service known as 911 has sold access to hundreds of thousands of Microsoft Windows computers daily, allowing customers to route their Internet traffic through PCs in virtually any country or city around the globe — but predominantly in the United States. 911 says its network is made up entirely of users who voluntarily install its “free VPN” software. But new research shows the proxy service has a long history of purchasing installations via shady “pay-per-install” affiliate marketing schemes, some of which 911 operated on its own.
911[.]re is one of the original “residential proxy” networks, which allow someone to rent a residential IP address to use as a relay for his/her Internet communications, providing anonymity and the advantage of being perceived as a residential user surfing the web.
From a website’s perspective, the IP traffic of a residential proxy network user appears to originate from the rented residential IP address, not from the proxy service customer. These services can be used in a legitimate manner for several business purposes — such as price comparisons or sales intelligence — but they are massively abused for hiding cybercrime activity because they can make it difficult to trace malicious traffic to its original source.
Residential proxy services are often marketed to people seeking the ability to evade country-specific blocking by the major movie and media streaming providers. But some of them — like 911 — build their networks in part by offering “free VPN” or “free proxy” services that are powered by software which turns the user’s PC into a traffic relay for other users. In this scenario, users indeed get to use a free VPN service, but they are often unaware that doing so will turn their computer into a proxy that lets others use their Internet address to transact online.
The current prices for 911’s proxies.
Researchers at the University of Sherbrooke in Canada recently published an analysis of 911, and found there were roughly 120,000 PCs for rent via the service, with the largest number of them located in the United States.
“The 911[.]re network uses at least two free VPN services to lure its users to install a malware-like software that achieves persistence on the user’s computer,” the researchers wrote. “During the research we identified two free VPN services that [use] a subterfuge to lure users to install software that looks legitimate but makes them part of the network. These two software are currently unknown to most if not all antivirus companies.”
A depiction of the Proxygate service. Image: University of Sherbrooke.
The researchers concluded that 911 is supported by a “mid scale botnet-like infrastructure that operates in several networks, such as corporate, government and critical infrastructure.” The Canadian team said they found many of the 911 nodes available for rent were situated within several major US-based universities and colleges, critical infrastructures such as clean water, defense contractors, law enforcement and government networks.
Highlighting the risk that 911 nodes could pose to internal corporate networks, they observed that “the infection of a node enables the 911.re user to access shared resources on the network such as local intranet portals or other services.”
“It also enables the end user to probe the LAN network of the infected node,” the paper continues. “Using the internal router, it would be possible to poison the DNS cache of the LAN router of the infected node, enabling further attacks.”
The 911 user interface, as it existed when the service first launched in 2016.
A review of the clues left behind by 911’s early days on the Internet paint a more complete picture of this long-running proxy network. The domain names used by 911 over the years have a few common elements in their original WHOIS registration records, including the address ustraffic@qq.com and a Yunhe Wang from Beijing.
That ustraffic email is tied to a small number of interesting domains, including browsingguard[.]com, cleantraffic[.]net, execlean[.]net, proxygate[.]net, and flashupdate[.]net.
A cached copy of flashupdate[.]net available at the Wayback Machine shows that in 2016 this domain was used for the “ExE Bucks” affiliate program, a pay-per-install business which catered to people already running large collections of hacked computers or compromised websites. Affiliates were paid a set amount for each installation of the software, with higher commissions for installs in more desirable nations, particularly Europe, Canada and the United States.
“We load only one software — it’s a Socks5 proxy program,” read the message to ExE Bucks affiliates. The website said affiliates were free to spread the proxy software by any means available (i.e. “all promotion methods allowed”). The website’s copyright suggests the ExE Bucks affiliate program dates back to 2012.
A cached copy of flashupdate[.]net circa 2016, which shows it was the home of a pay-per-install affiliate program that incentivized the silent installation of its software. “FUD” in the ad above refers to software and download links that are “Fully UnDetectable” as suspicious or malicious by all antivirus software.
Another domain tied to the ustraffic@qq.com email in 2016 was ExeClean[.]net, a service that advertised to cybercriminals seeking to obfuscate their malicious software so that it goes undetected by all or at least most of the major antivirus products on the market.
“Our technology ensures the maximum security from reverse engineering and antivirus detections,” ExEClean promised.
The Exe Clean service made malware look like goodware to antivirus products.
Yet another domain connected to the ustraffic email is p2pshare[.]net, which advertised “free unlimited internet file-sharing platform” for those who agreed to install their software.
p2pshare.net, which bundled 911 proxy with an application that promised access to free unlimited internet file-sharing.
Still more domains associated with ustraffic@qq.com suggest 911’s proxy has been disguised as security updates for video player plugins, including flashplayerupdate[.]xyz, mediaplayerupdate[.]xyz, and videoplayerupdate[.]xyz.
The earliest version of the 911 website available from the Wayback Machine is from 2016. A sister service called proxygate[.]net launched roughly a year prior to 911 as a “free” public test of the budding new residential proxy service. “Basically using clients to route for everyone,” was how Proxygate described itself in 2016.
For more than a year after its founding, the 911 website was written entirely in Simplified Chinese. The service has only ever accepted payment via virtual currencies such as Bitcoin and Monero, as well as Alipay and China UnionPay, both payment platforms based in China.
Initially, the terms and conditions of 911’s “End User License Agreement (EULA) named a company called Wugaa Enterprises LLC, which was registered in California in 2016. Records from the California Secretary of State office show that in November 2016, Wugaa Enterprises said it was in the Internet advertising business, and had named as its CEO as one Nicolae Aurelian Mazgarean of Brasov, Romania.
A search of European VAT numbers shows the same Brasov, RO address tied to an enterprise called PPC Leads SRL (in the context of affiliate-based marketing, “PPC” generally refers to the term “pay-per-click”).
911’s EULA would later change its company name and address in 2017, to International Media Ltd. in the British Virgin Islands. That is the same information currently displayed on the 911 website.
The EULA attached to 911 software downloaded from browsingguard[.]com (tied to the same ustraffic@qq email that registered 911) references a company called Gold Click Limited. According to the UK Companies House, Gold Click Limited was registered in 2016 to a 34-year-old Yunhe Wang from Beijing City. Many of the WHOIS records for the above mentioned domains also include the name Yunhe Wang, or some variation thereof.
In a response to questions from KrebsOnSecurity, 911 said the researchers were wrong, and that 911 has nothing to do with any of the other domains mentioned above.
“We have 911 SDK link and how it works described clearly in the “Terms of use” of affiliated partners products, and we have details of how the community powered network works on our webpages,” read an email response.
“Besides that, for protecting the end users, we banned many domains’ access and blocked the vulnerable ports, e.g. spamming emails, and torrent is not possible from the 911 network,” the reply continued. “Same as scanning and many others…Accessing to the Lan network and router is also blocked. We are monitoring 911 user’s account closely, once any abnormal behavior detected, we suspend the user’s account right away.”
911 has remained one of the most popular services among denizens of the cybercrime underground for years, becoming almost shorthand for connecting to that “last mile” of cybercrime. Namely, the ability to route one’s malicious traffic through a computer that is geographically close to the consumer whose credit card they’re about to charge at some website, or whose bank account they’re about to empty.
Given the frequency with which 911 has been praised by cybercrooks on the top forums, it was odd to find the proprietors of 911 do not appear to have created any official support account for the service on any of several dozen forums reviewed by this author going back a decade. However there are two cybercriminal identities on the forums that have responded to individual 911 help requests, and who promoted the sale of 911 accounts via their handles.
Both of these identities were active on the crime forum fl.l33t[.]su between 2016 and 2019. The user “Transfer” advertised and sold access to 911 from 2016 to 2018, amid many sales threads where they advertised expensive electronics and other consumer goods that were bought online with stolen credit cards.
In a 2017 discussion on fl.l33t[.]su, the user who picked the handle “527865713” could be seen answering private messages in response to help inquiries seeking someone at 911. That identity is tied to an individual who for years advertised the ability to receive and relay large wire transfers from China.
One ad from this user in 2016 offered a “China wire service” focusing on Western Union payments, where “all transfers are accepted in China.” The service charged 20 percent of all “scam wires,” unauthorized wire transfers resulting from bank account takeovers or scams like CEO impersonation schemes.
In August 2021, 911’s biggest competitor — a 15-year-old proxy network built on malware-compromised PCs called VIP72 — abruptly closed up shop. Almost overnight, an overwhelming number of former VIP72 customers began shifting their proxy activities to 911.
The login page for VIP72, until recently 911’s largest competitor.
That’s according to Riley Kilmer, co-founder of Spur.us — a security company that monitors anonymity services. Kilmer said 911 also gained an influx of new customers after the Jan. 2022 closure of LuxSocks, another malware-based proxy network.
“911’s user base skyrocketed after VIP72 and then LuxSocks went away,” Kilmer said. “And it’s not hard to see why. 911 and VIP72 are both Windows-based apps that operate in a similar way, where you buy private access to IPs.”
Kilmer said 911 is interesting because it appears to be based in China, while nearly all of the other major proxy networks are Russian-backed or Russian-based.
“They have two basic methods to get new IPs,” Kilmer said. “The free VPN apps, and the other is trojanized torrents. They’ll re-upload Photoshop and stuff like that so that it’s backdoored with the 911 proxy. They claim the proxy is bundled with legitimate software and that users all agree to their Terms of Service, meanwhile they can hide behind the claim that it was some affiliate who installed the software, not them.”
Kilmer said at last count, 911 had nearly 200,000 proxy nodes for sale, spanning more than 200 countries: The largest geographic concentration is the United States, where more than 42,000 proxies are currently for rent by the service.
Beware of “free” or super low-cost VPN services. Proper VPN services are not cheap to operate, so the revenue for the service has to come from somewhere. And there are countless “free” VPN services that are anything but, as we’ve seen with 911.
In general, the rule of thumb for transacting online is that if you’re not the paying customer, then you and/or your devices are probably the product that’s being sold to others. Many free VPN services will enlist users as VPN nodes for others to use, and some even offset costs by collecting and reselling data from their users.
All VPN providers claim to prioritize the privacy of their users, but many then go on to collect and store all manner of personal and financial data from those customers. Others are fairly opaque about their data collection and retention policies.
I’ve largely avoided wading into the fray about which VPN services are best, but there are so many shady and just plain bad ones out there that I’d be remiss if I didn’t mention one VPN provider whose business practices and transparency of operation consistently distinguish them from the rest. If maintaining your privacy and anonymity are primary concerns for you as a VPN user, check out Mullvad.net.
Let me make clear that KrebsOnSecurity does not have any financial or business ties to this company (for the avoidance of doubt, this post doesn’t even link to them). I mention it only because I’ve long been impressed with their candor and openness, and because Mullvad goes out of its way to discourage customers from sharing personal or financial data.
To that end, Mullvad will even accept mailed payments of cash to fund accounts, quite a rarity these days. More importantly, the service doesn’t ask users to share phone numbers, email addresses or any other personal information. Nor does it require customers to create passwords: Each subscription can be activated just by entering a Mullvad account number (woe to those who lose their account number).
I wish more companies would observe this remarkably economical security practice, which boils down to the mantra, “You don’t have to protect what you don’t collect.”
Update, July 24, 11:15 a.m. ET: 911’s homepage now includes a banner saying the service has halted new registrations and payments. “We are reviewing our network and adding a series of security measures to prevent misuse of our services,” the message reads. “Proxy balance top-up and new user registration are closed. We are reviewing every existing user, to ensure their usage is legit and [in] compliance with our Terms of Service.”
Update, July 30, 10:07 a.m. ET: 911 announced on July 28 that it is permanently closing down, following a series of data breaches this month that 911 says resulted in the deletion of customer data.
Give the gift of security resilience and receive instant savings from a secure choice enterprise agreement.
When it comes to the holidays, most thoughts turn towards shopping and spending time with friends and loved ones. In the business world, the holiday season often lands at the end of the quarter / fiscal year, and businesses start to make lists of things that need to be purchased in the coming years, and sometimes they find themselves wanting to purchase a gift – so to speak – for themselves.
The problem that many organizations face is that when it comes to purchasing products and services, balancing today’s needs and budget isn’t as easy as it sounds. Add to this the concern of unclear future security needs which can be stressful. But what if you could get exactly what you need, protect the budget and future-proof your investment at the same time?
We want to give a gift to you. That is right, you read that correctly. We want to make your holidays a little bit more special with the gift of security resilience. And we can offer that to you with instant savings.
Here are a few examples of how you can build the gift of security resilience that best fits your organization’s security needs today and is ready to grow with your tomorrow.
Provide edge to edge protection. Hold the first line of defense against cyberthreats for branch offices and remote users. Maintain the last line of defense, by protecting your endpoint devices with rapid incident detection, response, and remediation of advanced threats.
Provide protection for your users and devices with these essential Cisco Secure products.
Protect what matters, get cloud and application protection that secures internet access, safeguards cloud app usage, and identifies public cloud threats. Build out your cloud and application security with these essential Cisco Secure products.
Cisco Secure Zero Trust helps you transform your business with continuous verification of users and devices for secure access. These Cisco Secure products are part of the essential architecture towards building zero trust secure access.
Choose any of the two Cisco Secure products that you want to buy towards building out user and device security, cloud and application security, zero trust secure access, or any of our security solutions. You do not have to stop with two, you have the freedom to grow; add more, save more.
Cisco Secure products you can choose from:
Give the Gift of Security with a Cisco Secure Choice Enterprise Agreement
Choose, buy, and deploy Cisco Secure products through one easy-to-manage Cisco Secure Choice Enterprise Agreement; save more as you buy more for all of those on your holiday list. Protect your end users working remotely, in office only, or in a hybrid environment as with more devices on and off the network, cybersecurity risks are not slowing down anytime soon. Build the solution that best fits your organization through a single, flexible agreement that lets you pay annually, as you go, over 3 or 5 years, with 0% financing.
With Cisco’s Secure Choice Enterprise Agreements, you can add security resilience in 2023 and beyond, with exactly the security products and services you need, right when you need them the most.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Microsoft on Tuesday released updates to quash at least 74 security bugs in its Windows operating systems and software. Two of those flaws are already being actively attacked, including an especially severe weakness in Microsoft Outlook that can be exploited without any user interaction.
The Outlook vulnerability (CVE-2023-23397) affects all versions of Microsoft Outlook from 2013 to the newest. Microsoft said it has seen evidence that attackers are exploiting this flaw, which can be done without any user interaction by sending a booby-trapped email that triggers automatically when retrieved by the email server — before the email is even viewed in the Preview Pane.
While CVE-2023-23397 is labeled as an “Elevation of Privilege” vulnerability, that label doesn’t accurately reflect its severity, said Kevin Breen, director of cyber threat research at Immersive Labs.
Known as an NTLM relay attack, it allows an attacker to get someone’s NTLM hash [Windows account password] and use it in an attack commonly referred to as “Pass The Hash.”
“The vulnerability effectively lets the attacker authenticate as a trusted individual without having to know the person’s password,” Breen said. “This is on par with an attacker having a valid password with access to an organization’s systems.”
Security firm Rapid7 points out that this bug affects self-hosted versions of Outlook like Microsoft 365 Apps for Enterprise, but Microsoft-hosted online services like Microsoft 365 are not vulnerable.
The other zero-day flaw being actively exploited in the wild — CVE-2023-24880 — is a “Security Feature Bypass” in Windows SmartScreen, part of Microsoft’s slate of endpoint protection tools.
Patch management vendor Action1 notes that the exploit for this bug is low in complexity and requires no special privileges. But it does require some user interaction, and can’t be used to gain access to private information or privileges. However, the flaw can allow other malicious code to run without being detected by SmartScreen reputation checks.
Dustin Childs, head of threat awareness at Trend Micro’s Zero Day Initiative, said CVE-2023-24880 allows attackers to create files that would bypass Mark of the Web (MOTW) defenses.
“Protective measures like SmartScreen and Protected View in Microsoft Office rely on MOTW, so bypassing these makes it easier for threat actors to spread malware via crafted documents and other infected files that would otherwise be stopped by SmartScreen,” Childs said.
Seven other vulnerabilities Microsoft patched this week earned its most-dire “critical” severity label, meaning the updates address security holes that could be exploited to give the attacker full, remote control over a Windows host with little or no interaction from the user.
Also this week, Adobe released eight patches addressing a whopping 105 security holes across a variety of products, including Adobe Photoshop, Cold Fusion, Experience Manager, Dimension, Commerce, Magento, Substance 3D Stager, Cloud Desktop Application, and Illustrator.
For a more granular rundown on the updates released today, see the SANS Internet Storm Center roundup. If today’s updates cause any stability or usability issues in Windows, AskWoody.com will likely have the lowdown on that.
Please consider backing up your data and/or imaging your system before applying any updates. And feel free to sound off in the comments if you experience any problems as a result of these patches.
There has been an exponential increase in breaches within enterprises despite the carefully constructed and controlled perimeters that exist around applications and data. Once an attacker can access… Read more on Cisco Blogs
Related tags
FreshRSS