RSS Security

❌ About FreshRSS
There are new articles available, click to refresh the page.
Before yesterdayMcAfee Blogs

Major HTTP Vulnerability in Windows Could Lead to Wormable Exploit

12 May 2021 at 15:48
AI Cyber Security

Today, Microsoft released a highly critical vulnerability (CVE-2021-31166) in its web server http.sys. This product is a Windows-only HTTP server which can be run standalone or in conjunction with IIS (Internet Information Services) and is used to broker internet traffic via HTTP network requests. The vulnerability is very similar to CVE-2015-1635, another Microsoft vulnerability in the HTTP network stack reported in 2015.

With a CVSS score of 9.8, the vulnerability announced has the potential to be both directly impactful and is also exceptionally simple to exploit, leading to a remote and unauthenticated denial-of-service (Blue Screen of Death) for affected products.

The issue is due to Windows improperly tracking pointers while processing objects in network packets containing HTTP requests. As HTTP.SYS is implemented as a kernel driver, exploitation of this bug will result in at least a Blue Screen of Death (BSoD), and in the worst-case scenario, remote code execution, which could be wormable. While this vulnerability is exceptional in terms of potential impact and ease of exploitation, it remains to be seen whether effective code execution will be achieved. Furthermore, this vulnerability only affects the latest versions of Windows 10 and Windows Server (2004 and 20H2), meaning that the exposure for internet-facing enterprise servers is fairly limited, as many of these systems run Long Term Servicing Channel (LTSC) versions, such as Windows Server 2016 and 2019, which are not susceptible to this flaw.

At the time of this writing, we are unaware of any “in-the-wild” exploitation for CVE-2021-31166 but will continue to monitor the threat landscape and provide relevant updates. We urge Windows users to apply the patch immediately wherever possible, giving special attention to externally facing devices that could be compromised from the internet. For those who are unable to apply Microsoft’s update, we are providing a “virtual patch” in the form of a network IPS signature that can be used to detect and prevent exploitation attempts for this vulnerability.

McAfee Network Security Platform (NSP) Protection
Sigset Version:
Attack ID: 0x4528f000
Attack Name: HTTP: Microsoft HTTP Protocol Stack Remote Code Execution Vulnerability (CVE-2021-31166)

McAfee Knowledge Base Article KB94510:



The post Major HTTP Vulnerability in Windows Could Lead to Wormable Exploit appeared first on McAfee Blogs.

What’s in the Box? Part II: Hacking the iParcelBox

18 June 2020 at 07:01

Package delivery is just one of those things we take for granted these days. This is especially true in the age of Coronavirus, where e-commerce and at-home deliveries make up a growing portion of consumer buying habits.

In 2019, McAfee Advanced Threat Research (ATR) conducted a vulnerability research project on a secure home package delivery product, known as BoxLock. The corresponding blog can be found here and highlights a vulnerability we found in the Bluetooth Low Energy (BLE) configuration used by the device. Ultimately, the flaw allowed us to unlock any BoxLock in Bluetooth range with a standard app from the Apple or Google store.

Shortly after we released this blog, a similar product company based in the UK reached out to the primary researcher (Sam Quinn) here at McAfee ATR, requesting that the team perform research analysis on his product, called the iParcelBox. This device is comprised of a secure steel container with a push-button on the outside, allowing for package couriers to request access to the delivery container with a simple button press, notifying the homeowner via the app and allowing remote open/close functions.

iParcelBox – Secure Package Delivery & iParcelBox App

The researcher was able to take a unique spin on this project by performing OSINT (Open Source Intelligence), which is the practice of using publicly available information, often unintentionally publicized, to compromise a device, system or user. In this case, the primary developer for the product wasn’t practicing secure data hygiene for his online posts, which allowed the researcher to discover information that dramatically shortened what would have been a much more complicated project. He discovered administrative credentials and corresponding internal design and configurations, effectively providing the team access to any and all iParcelBox devices worldwide, including the ability to unlock any device at a whim. All test cases were executed on lab devices owned by the team or approved by iParcelBox. Further details of the entire research process can be found in the full technical version of the research blog here.

The actual internals of the system were well-designed from a security perspective, utilizing concepts like SSL for encryption, disabling hardware debugging, and performing proper authentication checks. Unfortunately, this level of design and security were all undermined by the simple fact that credentials were not properly protected online. Armed with these credentials the researcher was able to extract sensitive certificates, keys, device passwords, and WIFI passwords off any iParcelBox.

Secondly, as the researcher prepared the writeup on the OSINT techniques used for this, he made a further discovery. When analyzing the configuration used by the Android app to interact with the cloud-based IOT framework (AWS-IOT), he found that even without an administrative password, he could leak plaintext temporary credentials to query the AWS database. These credentials had a permission misconfiguration which allowed the researcher to query all the information about any iParcelBox device and to become the primary owner.

In both cases, to target a device, an attacker would need to know the MAC address of the victim’s iParcelBox; however, the iParcelBox MAC addresses appeared to be generated non-randomly and were simple to guess.

A typical research effort for McAfee ATR involves complex hardware analysis, reverse engineering, exploit development and much more. While the developer made some high-level mistakes regarding configuration and data hygiene, we want to take a moment to recognize the level of effort put into both physical and digital security. iParcelBox implemented numerous security concepts that are uncommon for IOT devices and significantly raise the bar for attackers. It’s much easier to fix issues like leaked passwords or basic configuration issues than to rebuild hardware or reprogram software to bolt on security after the fact. This may be why the company was able to fix both issues almost immediately after we informed them in March of 2020. We’re thrilled to see more and more companies of all sizes embracing the security research community and collaborating quickly to improve their products, even from the beginning of the development cycle.

What can be done?

For consumers:

Even developers are subject to the same issues we all have; choosing secure and complex passwords, protecting important credentials, practicing security hygiene, and choosing secure configurations when implementing controls for a device. As always, we encourage you to evaluate the vendor’s approach to security. Do they embrace and encourage vulnerability research on their products? How quick are they to implement fixes and are they done correctly? Nearly every product on the market will have security flaws if you look hard enough, but the way they are handled is arguably more important than the flaws themselves.

For developers and vendors:

This case study should provide a valuable testament to the power of community. Don’t be afraid to engage security researchers and embrace the discovery of vulnerabilities. The more critical the finding, the better! Work with researchers or research companies that practice responsible disclosure, such as McAfee ATR. Additionally, it can be easy to overlook the simple things such as the unintentional leak of critical data found during this project. A security checklist should include both complex and simple steps to ensure the product maintains proper security controls and essential data is protected and periodically audited.

The post What’s in the Box? Part II: Hacking the iParcelBox appeared first on McAfee Blogs.

Model Hacking ADAS to Pave Safer Roads for Autonomous Vehicles

19 February 2020 at 09:01

The last several years have been fascinating for those of us who have been eagerly observing the steady move towards autonomous driving. While semi-autonomous vehicles have existed for many years, the vision of fleets of fully autonomous vehicles operating as a single connected entity is very much still a thing of the future. However, the latest technical advances in this area bring us a unique and compelling picture of some of the capabilities we might expect to see “down the road.” Pun intended.

For example, nearly every new vehicle produced in 2019 has a model which implements state-of-the art sensors that utilize analytics technologies, such as machine learning or artificial intelligence, and are designed to automate, assist or replace many of the functions humans were formerly responsible for. These can range from rain-sensors on the windshield to control wiper blades, to object detection sensors using radar and lidar for collision avoidance, to camera systems capable of recognizing objects in range and providing direct driving input to the vehicle.

This broad adoption represents a fascinating development in our industry; it’s one of those very rare times when researchers can lead the curve ahead of adversaries in identifying weaknesses in underlying systems.

McAfee Advanced Threat Research (ATR) has a specific goal: identify and illuminate a broad spectrum of threats in today’s complex landscape. With model hacking, the study of how adversaries could target and evade artificial intelligence, we have an incredible opportunity to influence the awareness, understanding and development of more secure technologies before they are implemented in a way that has real value to the adversary.

With this in mind, we decided to focus our efforts on the broadly deployed MobilEye camera system, today utilized across over 40 million vehicles, including Tesla models that implement Hardware Pack 1.

18 Months of Research

McAfee Advanced Threat Research follows a responsible disclosure policy, as stated on our website. As such, we disclosed the findings below to both Tesla and MobilEye 90 days prior to public disclosure. McAfee disclosed the findings to Tesla on September 27th, 2019 and MobilEye on October 3rd, 2019. Both vendors indicated interest and were grateful for the research but have not expressed any current plans to address the issue on the existing platform. MobilEye did indicate that the more recent version(s) of the camera system address these use cases.

MobilEye is one of the leading vendors of Advanced Driver Assist Systems (ADAS) catering to some of the world’s most advanced automotive companies. Tesla, on the other hand, is a name synonymous with ground-breaking innovation, providing the world with the innovative and eco-friendly smart cars.


MobilEye camera sensor
A table showing MobilEye’s EyeQ3 being used in Tesla’s hardware pack 1.

As we briefly mention above, McAfee Advanced Threat Research has been studying what we call “Model Hacking,” also known in the industry as adversarial machine learning. Model Hacking is the concept of exploiting weaknesses universally present in machine learning algorithms to achieve adverse results. We do this to identify the upcoming problems in an industry that is evolving technology at a pace that security has not kept up with.

We started our journey into the world of model hacking by replicating industry papers on methods of attacking machine learning image classifier systems used in autonomous vehicles, with a focus on causing misclassifications of traffic signs. We were able to reproduce and significantly expand upon previous research focused on stop signs, including both targeted attacks, which aim for a specific misclassification, as well as untargeted attacks, which don’t prescribe what an image is misclassified as, just that it is misclassified. Ultimately, we were successful in creating extremely efficient digital attacks which could cause misclassifications of a highly robust classifier, built to determine with high precision and accuracy what it is looking at, approaching 100% confidence.

Targeted digital white-box attack on stop sign, causing custom traffic sign classifier to misclassify as 35-mph speed sign

We further expanded our efforts to create physical stickers, shown below, that model the same type of perturbations, or digital changes to the original photo, which trigger weaknesses in the classifier and cause it to misclassify the target image.

Targeted physical white-box attack on stop sign, causing custom traffic sign classifier to misclassify the stop sign as an added lane sign

This set of stickers has been specifically created with the right combination of color, size and location on the target sign to cause a robust webcam-based image classifier to think it is looking at an “Added Lane” sign instead of a stop sign.

Video demo of our resilient classifier in the lab which correctly recognizes the 35-mph speed limit sign, even when it is partially obstructed

In reality, modern vehicles don’t yet rely on stop signs to enable any kind of autonomous features such as applying the brakes, so we decided to alter our approach and shift (pun intended) over to speed limit signs. We knew, for example, that the MobilEye camera is used by some vehicles to determine the speed limit, display it on the heads-up display (HUD), and potentially even feed that speed limit to certain features of the car related to autonomous driving. We’ll come back to that!

We then repeated the stop sign experiments on traffic signs, using a highly robust classifier, and our trusty high-resolution webcam. And just to show how robust our classifier is, we can make many changes to the sign— block it partially, place the stickers in random locations — and the classifier does an outstanding job of correctly predicting the true sign, as demonstrated in the video above. While there were many obstacles to achieving the same success, we were ultimately able to prove both targeted and untargeted attacks, digitally and physically, against speed limit signs. The below images highlight a few of those tests.

Example of targeted digital perturbations printed out using a black and white printer which cause a misclassification of 35-mph speed sign to 45-mph speed sign.

At this point, you might be wondering “what’s so special about tricking a webcam into misclassifying a speed limit sign, outside of just the cool factor?” Not much, really. We felt the same, and decided it was time to test the “black box theory.”

What this means, in its most simple form, is attacks leveraging model hacking which are trained and executed against white box, also known as open source systems, will successfully transfer to black box, or fully closed and proprietary systems, so long as the features and properties of the attack are similar enough. For example, if one system is relying on the specific numeric values of the pixels of an image to classify it, the attack should replicate on another camera system that relies on pixel-based features as well.

The last part of our lab-based testing involved simplifying this attack and applying it to a real-world target. We wondered if the MobilEye camera was as robust as the webcam-based classifier we built in the lab? Would it truly require several highly specific, and easily noticeable stickers to cause a misclassification? Thanks to several friendly office employees, we were able to run repeated tests on a 2016 Model “S” and 2016 Model “X” Tesla using the MobilEye camera (Tesla’s hardware pack 1 with EyeQ3 mobilEye chip). The first test involved simply attempting to recreate the physical sticker test – and, it worked, almost immediately and with a high rate of reproducibility.

In our lab tests, we had developed attacks that were resistant to change in angle, lighting and even reflectivity, knowing this would emulate real-world conditions. While these weren’t perfect, our results were relatively consistent in getting the MobilEye camera to think it was looking at a different speed limit sign than it was. The next step in our testing was to reduce the number of stickers to determine at which point they failed to cause a misclassification. As we began, we realized that the HUD continued to misclassify the speed limit sign. We continued reducing stickers from 4 adversarial stickers in the only locations possible to confuse our webcam, all the way down to a single piece of black electrical tape, approximately 2 inches long, and extending the middle of the 3 on the traffic sign.

A robust, inconspicuous black sticker achieves a misclassification from the Tesla model S, used for Speed Assist when activating TACC (Traffic Aware Cruise Control)

Even to a trained eye, this hardly looks suspicious or malicious, and many who saw it didn’t realize the sign had been altered at all. This tiny piece of sticker was all it took to make the MobilEye camera’s top prediction for the sign to be 85 mph.


The finish line was close (last pun…probably).

Finally, we began to investigate whether any of the features of the camera sensor might directly affect any of the mechanical, and even more relevant, autonomous features of the car. After extensive study, we came across a forum referencing the fact that a feature known as Tesla Automatic Cruise Control (TACC) could use speed limit signs as input to set the vehicle speed.

There was majority of consensus among owners that this might be a supported feature. It was clear that there was also confusion among forum members as to whether this capability was possible, so our next step was to verify by consulting Tesla software updates and new feature releases.

A software release for TACC contained just enough information to point us towards speed assist, with the following statement, under the Tesla Automatic Cruise Control feature description.

“You can now immediately adjust your set speed to the speed determined by Speed Assist.”

This took us down our final documentation-searching rabbit hole; Speed Assist, a feature quietly rolled out by Tesla in 2014.

Finally! We can now add these all up to surmise that it might be possible, for Tesla models enabled with Speed Assist (SA) and Tesla Automatic Cruise Control (TACC), to use our simple modification to a traffic sign to cause the car to increase speed on its own!

Despite being confident this was theoretically possible, we decided to simply run some tests to see for ourselves.

McAfee ATR’s lead researcher on the project, Shivangee Trivedi, partnered with another of our vulnerability researchers Mark Bereza, who just so happened to own a Tesla that exhibited all these features. Thanks Mark!

For an exhaustive look at the number of tests, conditions, and equipment used to replicate and verify misclassification on this target, we have published our test matrix here.

The ultimate finding here is that we were able to achieve the original goal. By making a tiny sticker-based modification to our speed limit sign, we were able to cause a targeted misclassification of the MobilEye camera on a Tesla and use it to cause the vehicle to autonomously speed up to 85 mph when reading a 35-mph sign. For safety reasons, the video demonstration shows the speed start to spike and TACC accelerate on its way to 85, but given our test conditions, we apply the brakes well before it reaches target speed. It is worth noting that this is seemingly only possible on the first implementation of TACC when the driver double taps the lever, engaging TACC. If the misclassification is successful, the autopilot engages 100% of the time. This quick demo video shows all these concepts coming together.

Of note is that all these findings were tested against earlier versions (Tesla hardware pack 1, mobilEye version EyeQ3) of the MobilEye camera platform. We did get access to a 2020 vehicle implementing the latest version of the MobilEye camera and were pleased to see it did not appear to be susceptible to this attack vector or misclassification, though our testing was very limited. We’re thrilled to see that MobilEye appears to have embraced the community of researchers working to solve this issue and are working to improve the resilience of their product. Still, it will be quite some time before the latest MobilEye camera platform is widely deployed. The vulnerable version of the camera continues to account for a sizeable installation base among Tesla vehicles. The newest models of Tesla vehicles do not implement MobilEye technology any longer, and do not currently appear to support traffic sign recognition at all.

Looking Forward

We feel it is important to close this blog with a reality check. Is there a feasible scenario where an adversary could leverage this type of an attack to cause harm? Yes, but in reality, this work is highly academic at this time. Still, it represents some of the most important work we as an industry can focus on to get ahead of the problem. If vendors and researchers can work together to identify and solve these problems in advance, it would truly be an incredible win for us all. We’ll leave you with this:

In order to drive success in this key industry and shift the perception that machine learning systems are secure, we need to accelerate discussions and awareness of the problems and steer the direction and development of next-generation technologies. Puns intended.


The post Model Hacking ADAS to Pave Safer Roads for Autonomous Vehicles appeared first on McAfee Blogs.

Introduction and Application of Model Hacking

19 February 2020 at 09:01

Catherine Huang, Ph.D., and Shivangee Trivedi contributed to this blog.

The term “Adversarial Machine Learning” (AML) is a mouthful!  The term describes a research field regarding the study and design of adversarial attacks targeting Artificial Intelligence (AI) models and features.  Even this simple definition can send the most knowledgeable security practitioner running!  We’ve coined the easier term “model hacking” to enhance the reader’s comprehension of this increasing threat.  In this blog, we will decipher this very important topic and provide examples of the real-world implications, including findings stemming from the combined efforts of McAfee’s Advanced Analytic Team (AAT) and Advanced Threat Research (ATR) for a critical threat in autonomous driving.

  1. First, the Basics

AI is interpreted by most markets to include Machine Learning (ML), Deep Learning (DL), and actual AI, and we will succumb to using this general term of AI here.  Within AI, the model – a mathematical algorithm that provides insights to enable business results – can be attacked without knowledge of the actual model created.  Features are those characteristics of a model that define the output desired.  Features can also be attacked without knowledge of the features used!  What we have just described is known as a “black box” attack in AML – not knowing the model and features – or “model hacking.”  Models and/or features can be known or unknown, increasing false positives or negatives, without security awareness unless these vulnerabilities are monitored and ultimately protected and corrected.

In the feedback learning loop of AI, recurrent training of the model occurs in order to comprehend new threats and keep the model current (see Figure 1).  With model hacking, the attacker can poison the Training Set.  However, the Test Set can also be hacked, causing false negatives to increase, evading the model’s intent and misclassifying a model’s decision.  Simply by perturbating – changing the magnitudes of a few features (such as pixels for images), zeros to ones/ones to zeros, or removing a few features – the attacker can wreak havoc in security operations with disastrous effects.  Hackers will continue to “ping” unobtrusively until they are rewarded with nefarious outcomes – and they don’t even have to attack with the same model that we are using initially!

Figure 1. The continuous feedback loop of AI learning.
  1. Digital Attacks of Images and Malware

Hackers’ goals can be targeted (specific features and one specific error class) or non-targeted (indiscriminate classifiers and more than one specific error class), digital (e.g., images, audio) or physical (e.g., speed limit sign).  Figure 2 shows a rockhopper penguin targeted digitally.  A white-box evasion example (we knew the model and the features), a few pixel changes and the poor penguin in now classified as a frying pan or a computer with excellent accuracy.

Figure 2. An evasion example of a white-box, targeted, and digital attack resulting in the penguin being detected as a desktop computer (85.54%) or a frying pan (93.07%) following pixel perturbations.

While most current model hacking research focuses on image recognition, we have investigated evasion attacks and mitigation methods for malware detection and static analysis.  We utilized DREBIN[1], an Android malware dataset, and replicated the results of Grosse, et al., 2016[2].  Utilizing 625 malware samples highlighting FakeInstaller, and 120k benign samples and 5.5K malware, we developed a four-layer deep neural network with about 1.5K features (see Figure 3).  However, following an evasion attack with only modifying less than 10 features, the malware evaded the neural net nearly 100%.  This, of course, is a concern to all of us.


Figure 3. Metrics of the malware dataset and sample sizes.



Using the CleverHans[1] open-source library’s Jacobian Saliency Map Approach (JSMA) algorithm, we generated perturbations creating adversarial examples.  Adversarial examples are inputs to ML models that an attacker has intentionally designed to cause the model to make a mistake[1].  The JSMA algorithm needs only a minimum number of features need to be modified.  Figure 4 demonstrates the original malware sample (detected as malware with 91% confidence).  After adding just two API calls in a white-box attack, the adversarial example is now detected with 100% confidence as benign. Obviously, that can be catastrophic!

Figure 4. Perturbations added to malware in the feature space resulting in a benign detection with 100% confidence.


In 2016, Papernot[5] demonstrated that an attacker doesn’t need to know the exact model that is utilized in detecting malware.  Demonstrating this theory of transferability in Figure 5, the attacker constructed a source (or substitute) model of a K-Nearest Neighbor (KNN) algorithm, creating adversarial examples, which targeted a Support Vector Machine (SVM) algorithm.  It resulted in an 82.16% success rate, ultimately proving that substitution and transferability of one model to another allows black-box attacks to be, not only possible, but highly successful.

Figure 5. Papernot’s 5 successful transferability of adversarial examples created from one model (K Nearest Neighbor or KNN) to attack another model (Support Vector Machine or SVM).


In a black-box attack, the DREBIN Android malware dataset was detected 92% as malware.  However, using a substitute model and transferring the adversarial examples to the victim (i.e., source) system, we were able to reduce the detection of the malware to nearly zero.  Another catastrophic example!

Figure 6. Demonstration of a black-box attack of DREBIN malware.
  1. Physical Attack of Traffic Signs

While malware represents the most common artifact deployed by cybercriminals to attack victims, numerous other targets exist that pose equal or perhaps even greater threats. Over the last 18 months, we have studied what has increasingly become an industry research trend: digital and physical attacks on traffic signs. Research in this area dates back several years and has since been replicated and enhanced in numerous publications. We initially set out to reproduce one of the original papers on the topic, and built a highly robust classifier, using an RGB (Red Green Blue) webcam to classify stop signs from the LISA[6] traffic sign data set. The model performed exceptionally well, handling lighting, viewing angles, and sign obstruction. Over a period of several months, we developed model hacking code to cause both untargeted and targeted attacks on the sign, in both the digital and physical realms. Following on this success, we extended the attack vector to speed limit signs, recognizing that modern vehicles increasingly implement camera-based speed limit sign detection, not just as input to the Heads-Up-Display (HUD) on the vehicle, but in some cases, as input to the actual driving policy of the vehicle. Ultimately, we discovered that minuscule modifications to speed limit signs could allow an attacker to influence the autonomous driving features of the vehicle, controlling the speed of the adaptive cruise control! For more detail on this research, please refer to our extensive blog post on the topic.

  1. Detecting and Protecting Against Model Hacking

The good news is that much like classic software vulnerabilities, model hacking is possible to defend against, and the industry is taking advantage of this rare opportunity to address the threat before it becomes of real value to the adversary. Detecting and protecting against model hacking continues to develop with many articles published weekly.

Detection methods include ensuring that all software patches have been installed, closely monitoring drift of False Positives and False Negatives, noting cause and effect of having to change thresholds, retraining frequently, and auditing decay in the field (i.e., model reliability).  Explainable AI (“XAI”) is being examined in the research field for answering “why did this NN make the decision it did?” but can also be applied to small changes in prioritized features to assess potential model hacking.  In addition, human-machine teaming is critical to ensure that machines are not working autonomously and have oversight from humans-in-the-loop.  Machines currently do not understand context; however, humans do and can consider all possible root causes and mitigations of a nearly imperceptible shift in metrics.

Protection methods commonly employed include many analytic solutions: Feature Squeezing and Reduction, Distillation, adding noise, Multiple Classifier System, Reject on Negative Impact (RONI), and many others, including combinatorial solutions.  There are pros and cons of each method, and the reader is encouraged to consider their specific ecosystem and security metrics to select the appropriate method.

  1. Model Hacking Threats and Ongoing Research

While there has been no documented report of model hacking in the wild yet, it is notable to see the increase of research over the past few years: from less than 50 literature articles in 2014 to over 1500 in 2020.  And it would be ignorant of us to assume that sophisticated hackers aren’t reading this literature.  It is also notable that, perhaps for the first time in cybersecurity, a body of researchers have proactively developed the attack, detection, and protection against these unique vulnerabilities.

We will continue to add to the greater body of knowledge of model hacking attacks as well as ensure the solutions we implement have built-in detection and protection.  Our research excels in targeting the latest algorithms, such as GANS (Generative Adversarial Networks) in malware detection, facial recognition, and image libraries.  We are also in process of transferring traffic sign model hacking to further real-world examples.

Lastly, we believe McAfee leads the security industry in this critical area. One aspect that sets McAfee apart is the unique relationship and cross-team collaboration between ATR and AAT. Each leverages its unique skillsets; ATR with in-depth and leading-edge security research capabilities, and AAT, through its world-class data analytics and artificial intelligence expertise. When combined, these teams are able to do something few can; predict, research, analyze and defend against threats in an emerging attack vector with unique components, before malicious actors have even begun to understand or weaponize the threat.

For further reading, please see any of the references cited, or “Introduction to Adversarial Machine Learning” at



[1] Courtesy of Technische Universitat Braunschweig.

[2] Grosse, Kathrin, Nicolas Papernot, et al. ”Adversarial Perturbations Against Deep Neural Networks for Malware Classification” Cornell University Library. 16 Jun 2016.

[3] Cleverhans: An adversarial example library for constructing attacks, building defenses, and benchmarking both located at

[4] Goodfellow, Ian, et al. “Generative Adversarial Nets”

[5] Papernot, Nicholas, et al. “Transferability in Machine Learning: from Phenomena to Black-Box Attacks using Adversarial Samples”

[6] LISA = Laboratory for Intelligent and Safe Automobiles

The post Introduction and Application of Model Hacking appeared first on McAfee Blogs.

CurveBall – An Unimaginative Pun but a Devastating Bug

18 January 2020 at 05:49

Enterprise customers looking for information on defending against Curveball can find information here.

2020 came in with a bang this year, and it wasn’t from the record-setting number of fireworks on display around the world to celebrate the new year. Instead, just over two weeks into the decade, the security world was rocked by a fix for CVE-2020-0601 introduced in Microsoft’s first patch Tuesday of the year. The bug was submitted by the National Security Administration (NSA) to Microsoft, and though initially deemed as only “important”, it didn’t take long for everyone to figure out this bug fundamentally undermines the entire concept of trust that we rely on to secure web sites and validate files. The vulnerability relies on ECC (Elliptic Curve Cryptography), which is a very common method of digitally signing certificates, including both those embedded in files as well as those used to secure web pages. It represents a mathematical combination of values that produce a public and private key for trusted exchange of information. Ignoring the intimate details for now, ECC allows us to validate that files we open or web pages we visit have been signed by a well-known and trusted authority. If that trust is broken, malicious actors can “fake” signed files and web sites and make them look to the average person as if they were still trusted or legitimately signed. The flaw lies in the Microsoft library crypt32.dll, which has two vulnerable functions. The bug is straightforward in that these functions only validate the encrypted public key value, and NOT the parameters of the ECC curve itself. What this means is that if an attacker can find the right mathematical combination of private key and the corresponding curve, they can generate the identical public key value as the trusted certificate authority, whomever that is. And since this is the only value checked by the vulnerable functions, the “malicious” or invalid parameters will be ignored, and the certificate will pass the trust check.

As soon as we caught wind of the flaw, McAfee’s Advanced Threat Research team set out to create a working proof-of-concept (PoC) that would allow us to trigger the bug, and ultimately create protections across a wide range of our products to secure our customers. We were able to accomplish this in a matter of hours, and within a day or two there were the first signs of public PoCs as the vulnerability became better understood and researchers discovered the relative ease of exploitation.

Let’s pause for a moment to celebrate the fact that (conspiracy theories aside) government and private sector came together to report, patch and publicly disclose a vulnerability before it was exploited in the wild. We also want to call out Microsoft’s Active Protections Program, which provided some basic details on the vulnerability allowing cyber security practitioners to get a bit of a head start on analysis.

The following provides some basic technical detail and timeline of the work we did to analyze, reverse engineer and develop working exploits for the bug.  This blog focuses primarily on the research efforts behind file signing certificates.  For a more in-depth analysis of the web vector, please see this post.

Creating the proof-of-concept

The starting point for simulating an attack was to have a clear understanding of where the problem was. An attacker could forge an ECC root certificate with the same public key as a Microsoft ECC Root CA, such as the ECC Product Root Certificate Authority 2018, but with different “parameters”, and it would still be recognized as a trusted Microsoft CA. The API would use the public key to identify the certificate but fail to verify that the parameters provided matched the ones that should go with the trusted public key.

There have been many instances of cryptography attacks that leveraged failure of an API to validate parameters (such as these two) and attackers exploiting this type of vulnerability. Hearing about invalid parameters should raise a red flag immediately.

To minimize effort, an important initial step is to find the right level of abstraction and details we need to care about. Minimal details on the bug refer to public key and curve parameters and nothing about specific signature details, so likely reading about how to generate public/private key in Elliptical Curve (EC) cryptography and how to define a curve should be enough.

The first part of this Wikipedia article defines most of what we need to know. There’s a point G that’s on the curve and is used to generate another point. To create a pair of public/private keys, we take a random number k (the private key) and multiply it by G to get the public key (Q). So, we have Q = k*G. How this works doesn’t really matter for this purpose, so long as the scalar multiplication behaves as we’d expect. The idea here is that knowing Q and G, it’s hard to recover k, but knowing k and G, it’s very easy to compute Q.

Rephrasing this in the perspective of the bug, we want to find a new k’ (a new private key) with different parameters (a new curve, or maybe a new G) so that the ECC math gives the same Q back. The easiest solution is to consider a new generator G’ that is equal to our target public key (G’= Q). This way, with k’=1 (a private key equal to 1) we get k’G’ = Q which would satisfy the constraints (finding a new private key and keeping the same public key).

The next step is to verify if we can actually specify a custom G’ while specifying the curve we want to use. Microsoft’s documentation is not especially clear about these details, but OpenSSL, one of the most common cryptography libraries, has a page describing how to generate EC key pairs and certificates. The following command shows the standard parameters of the P384 curve, the one used by the Microsoft ECC Root CA.

Elliptic Curve Parameter Values

We can see that one of the parameters is the Generator, so it seems possible to modify it.

Now we need to create a new key pair with explicit parameters (so all the parameters are contained in the key file, rather than just embedding the standard name of the curve) and modify them following our hypothesis. We replace the Generator G’ by the Q from Microsoft Certificate, we replace the private key k’ by 1 and lastly, we replace the public key Q’ of the certificate we just generated by the Q of the Microsoft certificate.

To make sure our modification is functional, and the modified key is a valid one, we use OpenSSL to sign a text file and successfully verify its signature.

Signing a text file and verifying the signature using the modified key pair (k’=1, G’=Q, Q’=Q)

From there, we followed a couple of tutorials to create a signing certificate using OpenSSL and signed custom binaries with signtool. Eventually we’re greeted with a signed executable that appeared to be signed with a valid certificate!

Spoofed/Forged Certificate Seemingly Signed by Microsoft ECC Root CA

Using Sysinternal’s SigChecker64.exe along with Rohitab’s API Monitor (which, ironically is on a site not using HTTPS) on an unpatched system with our PoC, we can clearly see the vulnerability in action by the return values of these functions.

Rohitab API Monitor – API Calls for Certificate Verification

Industry-wide vulnerabilities seem to be gaining critical mass and increasing visibility even to non-technical users. And, for once, the “cute” name for the vulnerability showed up relatively late in the process. Visibility is critical to progress, and an understanding and healthy respect for the potential impact are key factors in whether businesses and individuals quickly apply patches and dramatically reduce the threat vector. This is even more essential with a bug that is so easy to exploit, and likely to have an immediate exploitation impact in the wild.

McAfee Response

McAfee aggressively developed updates across its entire product lines.  Specific details can be found here.


The post CurveBall – An Unimaginative Pun but a Devastating Bug appeared first on McAfee Blogs.

The Tradeoff Between Convenience and Security – A Balancing Act for Consumers and Manufacturers

7 January 2020 at 05:01

This week McAfee Advanced Threat Research (ATR) published new findings, uncovering security flaws in two popular IoT devices: a connected garage door opener and a “smart” ring, which, amongst many uses, utilizes near field communication (NFC) to open door locks.

I’d like to use these cases as examples of a growing concern in the area of product security. The industry of consumer devices has seen some positive momentum for security in recent years. For example, just a few years back, nearly every consumer-grade router shipped with a default username and password, which, if left unchanged, represented a serious security concern for home networks. At a minimum, most routers at least now ship with a unique password printed on the physical device itself, dramatically increasing the overall network security. Despite positive changes such as this, there is a long way to go.

If we think about the history of garage doors, they began as a completely manual object, requiring the owner to lift or operate it physically. The first overhead garage door was invented in the early 1920s, and an electric version came to market just a few years later. While this improved the functionality of the device and allowed for “remote” entry, it wasn’t until many years later that an actual wireless remote was added, giving consumers the ability to allow wireless access into their home. This was the beginning of an interesting tradeoff for consumers – an obvious increase in convenience which introduced a potential new security concern.

The same concept applies to the front door. Most consumers still utilize physical keys to secure the front door to their homes. However, the introduction of NFC enabled home door locks, which can be opened using compatible smart rings, adds both convenience and potentially compromised security.

For example, upon investigating the McLear NFC Ring, McAfee ATR uncovered a design insecurity, which could allow an attacker to easily clone the NFC Ring and gain entry to a home utilizing an NFC enabled smart lock.

While the NFC Ring modernizes physical household security, the convenience that comes with technology implementation also introduces a security issue.

The issue here is at a higher level; where and when do we draw the line for convenience versus security? The numerous benefits technology enhancements bring are exciting and often highly valuable; but many are unaware of the lengths cyber criminals will go to (for example, we once uncovered a vulnerability in a coffee pot which we were able to leverage to gain access to a home Wi-Fi network) and the many ways new features can reduce the security of a system.

As we move towards automation and remote access to nearly every computerized system on the planet, it’s our shared responsibility to maintain awareness of this fact and demand a higher bar for the products that we buy.

So what can be done? The responsibility is shared between consumers and manufacturers, and there are a few options:

For consumers:

  • Practice proper cyber hygiene. From a technical perspective, consumers have many tools at their disposal, even when security concerns do manifest. Implement a strong password policy, put IoT devices on their own, separate, network, utilize dual-factor authentication when possible, minimize redundant systems and patch quickly when issues are found.
  • Do your research. Consumers should ensure they are aware of the security risks associated with products available on the market.

For product manufacturers:

  • Manufacturer supported awareness. Product manufacturers can help by clearly stating the level of security their product provides in comparison with the technology or component they seek to advance.

Embrace vulnerability disclosure. Threat actors are constantly tracking flaws which they can weaponize; conversely, threat researchers are constantly working to uncover and secure product vulnerabilities. By partnering with researchers and responding quickly, vendors have a unique opportunity

The post The Tradeoff Between Convenience and Security – A Balancing Act for Consumers and Manufacturers appeared first on McAfee Blogs.

Apple iOS Attack Underscores Importance of Threat Research

4 September 2019 at 20:21

The recent discovery of exploit chains targeting Apple iOS is the latest example of how cybercriminals can successfully operate malicious campaigns, undetected, through the use of zero-day vulnerabilities.

In this scenario, a threat actor or actors operated multiple compromised websites, using at least one or more zero-day vulnerabilities and numerous unique exploit chains and known vulnerabilities to compromise iPhones, even the latest versions of the operating system, for more than two years. It takes remarkable talent and resources to operate this kind of infrastructure without being detected, as potentially thousands of users were compromised without the campaign being identified.

Every villain necessitates a hero, and this campaign underscores the importance of threat research and responsible vulnerability disclosure. Cybercriminals are getting faster, smarter, and more dangerous with each day that passes. The collective power of a global community of researchers working together to identify and disclose critical vulnerabilities, such as those used in this attack, is an important way to make meaningful progress towards eliminating these types of malicious campaigns. Equally as important is dissecting attacks in their aftermath to expose unique and interesting characteristics and empower defenders and developers to mitigate these threats in the future. With that said, let’s take a look.

An Attack Hiding in Plain Sight

This attack is unique in that the implant was not operating stealthily and was uploading information without encryption. This means a user monitoring their network traffic would notice activity as their information was being uploaded to the attacker’s server in cleartext.

Further, there appears to be debug messages left in the code, so a user connecting their phone to their computer and reviewing console logs, would notice activity as well.

However, given the “closed” operating system on the iPhone, a user would need to take the extra step of connecting their phone to their computer in order to notice these attack indicators. Given this, even a power user would be likely to remain unaware of an infection.

The Value of iOS Exploits

Finding iOS exploits in general is challenging due to the proprietary codebase and modern security mitigations. However, the type of exploits that require no user interaction and result in full remote code execution are the most rare, valuable, and difficult to uncover.

Adding further complexity to the attack, many mobile device exploits today require more than a single vulnerability to be successful; in many cases, 3-4 bugs are required to achieve elevated remote code execution on a target system. This is typically due to mitigations such as sandboxes/containers, restrictions on code execution, and reduced user privileges, making a chain of vulnerabilities necessary. This complexity reduces the success rate of an attack based on the likelihood of one or more of the bugs being discovered and “burned,” or patched out by the vendor.

Apple is a strong player in the responsible disclosure arena, recently expanding its offering of up to $1 million USD for certain vulnerabilities. Vulnerability brokers, who resell vulnerabilities, will reportedly pay up to 3 million USD for zero-interaction remote code execution vulnerabilities on iOS. It’s easy to understand the value of bugs that don’t require interaction from the victim and result in full remote code execution. With the popularity of Apple’s operating systems across mobile devices and laptops, even these prices may be not be enough to encourage threat actors to choose to responsibly disclose their findings over more nefarious purposes.

The Power of Vulnerability Disclosure

Two of the most significant questions this discovery raises are how was this adversary able to operate for so long, primarily using known exploits, and what kind of impact were they able to achieve?

These questions bring us full circle to the value of vulnerability disclosure. Through hardware and software analysis and responsible disclosure, meaningful progress can be made towards exposing these types of vulnerabilities before they can be leveraged by bad actors for nefarious purposes.

The post Apple iOS Attack Underscores Importance of Threat Research appeared first on McAfee Blogs.

IoT Zero-Days – Is Belkin WeMo Smart Plug the Next Malware Target?

18 April 2019 at 20:14

Effective malware is typically developed with intention, targeting specific victims using either known or unknown vulnerabilities to achieve its primary functions. In this blog, we will explore a vulnerability submitted by McAfee Advanced Threat Research (ATR) and investigate a piece of malware that recently incorporated similar vulnerabilities. The takeaway from this blog is the increasing movement towards IoT-specific malware and the likelihood of this unique vulnerability being incorporated into future malware.

We are rapidly approaching the one-year mark for the date McAfee ATR disclosed to Belkin (a consumer electronics company) a critical, remote code execution vulnerability in the Belkin WeMo Insight smart plug.  The date was May 21st, 2018, and the disclosure included extensive details on the vulnerability (a buffer overflow), proof-of-concept, exploit code and even a video demo showing the impact, dropping into a root shell opened on the target device. We further blogged about how this device, once compromised, can be used to pivot to other devices inside the network, including smart TVs, surveillance cameras, and even fully patched non-IoT devices such as PCs. Initially, the vendor assured us they had a patch ready to go and would be rolling it out prior to our planned public disclosure. In January of 2019, Belkin patched a vulnerability in the Mr. Coffee Coffee Maker w/ WeMo, which McAfee ATR reported to Belkin on November 16th, 2018, and released publicly at Mobile World Congress in late February. We commend Belkin for an effective patch within the disclosure window, though we were somewhat surprised that this was the prioritized patch given the Mr. Coffee product with WeMo no longer appears to be produced or sold.

The Insight smart plug firmware update never materialized and, after attempts to try to communicate further, three months later, in accordance with our vulnerability disclosure policy, McAfee ATR disclosed the issue publicly on August 21st. Our hope is that vulnerability disclosures will encourage vendors to patch vulnerabilities, educate the security community on a vulnerable product to drive development of defenses and, ultimately, encourage developers to recognize the impact that insecure code development can have.

Fast forward nearly a year and, to the best of our knowledge this vulnerability, classified as CVE-2018-6692, is still a zero-day vulnerability.  As of April 10th, 2019, we have heard of plans for a patch towards the end of the month and are standing by to confirm. We intentionally did not release exploit code to the public, as we believe it tips the balance in favor of cyber criminals, but exploitation of this vulnerability, while challenging in some regards, is certainly straightforward for a determined attacker.

IoT-Specific Malware

Let’s focus now on why this vulnerability is enticing for malicious actors.  Recently, Trend Micro released a blog observing occasional in-the-wild detections for a malware known as Bashlite. This specific malware was recently updated to include IoT devices in its arsenal, specifically using a Metasploit module for a known vulnerability in the WeMo UPnP protocol. The vulnerability appears to be tied to a 2015 bug which was patched by Belkin and was used to fingerprint and exploit WeMo devices using the “SetSmartDevInfo” action and corresponding “SmartDevURL” argument.

We can say for certain that this Metasploit module is not targeting the same vulnerability submitted by McAfee ATR, which resides in the <EnergyPerUnitCostVersion> XML field, within the library.

Analysis of Bashlite and IOT Device Targets

After briefly analyzing a few samples of the malware (file hashes from the aforementioned blog), the device appears to check for default credentials and known vulnerabilities in multiple IoT devices. For example, I came across a tweet after finding reference to a password in the binary of “oelinux123”.

This IoT device is an Alcatel Mobile Wifi, which has a number of known/default passwords. Notice the top username/password combination of “root:oelinux123.” When we analyze the actual malware, we can observe the steps used to enumerate and scan for vulnerable devices.

Here is a reference from the popular binary disassembly tool IDA Pro showing the password “OELINUX123” used to access a mobile WiFi device.

The next image is a large “jump table” used to scan through and identify a range of devices or targets using known passwords or vulnerabilities.

Next is some output from the “Echobot” scanner employed by the malware used to report possible vulnerabilities in target devices from the above jump table.

The final screenshot shows a list of some of the hardcoded credentials used by the malware.

The “huigu309” password appears to be associated with Zhone and Alcatel Lucent routers. Both routers have had several known vulnerabilities, backdoors and hardcoded passwords built into the firmware.

There is no need to continue the analysis further as the point of this is not to analyze the Bashlite malware in depth, but I did think it was worth expanding on some of the capabilities briefly, to show this malware is programmed to target multiple IoT devices.

Now to the point! The simple fact that generic WeMo Metasploit modules were added to this indicates that Belkin WeMo makes an interesting enough target that an unpatched vulnerability would be compelling to add to the malware’s capabilities. Hence, we believe it is possible, perhaps even likely, that malware authors already have or are currently working on incorporating the unpatched WeMo Insight vulnerability into IoT malware. We will be closely following threats related to this zero-day and will update or add to this blog if malware embedding this vulnerability surfaces. If the vendor does produce an effective patch, it will be a step in the right direction to reduce the overall threat and likelihood of weaponizing the vulnerability in malware.

How to Protect Your Devices

As this vulnerability requires network access to exploit the device, we highly recommend users of IoT devices such as the WeMo Insight implement strong WIFI passwords, and further isolate IoT devices from critical devices using VLANs or network segmentation. McAfee Secure Home Platform users can enable whitelisting or blacklisting features for protection from malicious botnets attempting to exploit this vulnerability.

Call to Action for Vendors, Consumers and Enterprise

It should be plain to see there is some low-hanging fruit in the industry of securing IoT devices. While some of the obvious simple issues such as hardcoded credentials are unexplainable, we understand that true software vulnerabilities cannot always be avoided. However, we issue a call-to action for IoT vendors; these issues must be fixed, and quickly too. Threat actors are constantly tracking flaws which they can weaponize, and we see a prime example of this in the Bashlite malware, updated for IoT devices including Belkin WeMo. By listening to consumer’s asks for security, partnering with researchers closely to identify flaws, and having a fast and flexible response model, vendors have a unique opportunity to close the holes in the products the world is increasingly relying on. Consumers can take away the importance of basic security hygiene; applying security updates when available, practicing complex password policy for home networks and devices, and isolating critical devices or networks from IoT.  Enterprise readers should be aware that just because this is an IoT consumer device typically, does not mean corporate assets cannot be compromised.  Once a home network has been infiltrated, all devices on that same network should be considered at risk, including corporate laptops.  This is a common method for cyber criminals to cross the boundary between home and enterprise.

The post IoT Zero-Days – Is Belkin WeMo Smart Plug the Next Malware Target? appeared first on McAfee Blogs.

Beyond Clubhouse: Vulnerable Agora SDKs Still in Widespread Use

19 February 2021 at 00:21
Mobile Conferencing Apps Carry Risks

On February 17th, 2021, McAfee disclosed findings based on a 10-month long disclosure process with major video conferencing vendor Agora, Inc.  As we disclosed the findings to Agora in April 2020, this lengthy disclosure timeline represents a nonstandard process for McAfee but was a joint agreement with the vendor to allow sufficient time for the development and release of a secure SDK. The release of the SDK mitigating the vulnerability took place on December 17th, 2020. Given the implications of snooping and spying on video and audio calls, we felt it was important to provide Agora the extended disclosure time. The affected users of Agora include popular voice and video messaging apps, with one notable application being the popular new iOS app known as Clubhouse.


Clubhouse Application Screenshot

Clubhouse has made headlines recently as one of the newest players in the social networking sphere, rising in popularity after a series of high-profile users including Elon Musk, Kanye West and influencers in various geographies posted about the platform. Released in April of 2020, Clubhouse quickly carved out a niche in Chinese social media as the platform to discuss sensitive social and political topics – perhaps aided by its invite-only approach to membership – and the spotlight shined on it by these key players further propelled it into viral status early this year. Perhaps unsurprisingly, the application was blocked for use in China on February 8th, 2021.

Last week, Stanford Internet Observatory (SIO) released research regarding the popular Clubhouse app’s use of Agora real-time engagement software and suggested that Agora could have provided the Chinese government access to Clubhouse user information and communications.  While the details of Stanford’s disclosure focus on the audio SDK compared to our work on the video SDK, the functionality and flaw are similar to our recent disclosure, CVE-2020-25605.  This includes the plaintext transmission of app ID, channel ID and token – credentials necessary to join either audio or video calls. We can confirm that Clubhouse updated to the most recent version of the Agora SDK on February 16th – just a day prior to our public disclosure.

Despite the recent noise surrounding Clubhouse, the reality is that this application is just one of many applications that leverage the Agora SDK. Among others, we investigated the social apps eHarmony, Skout, and MeetMe, along with several widely-used healthcare apps, some of which have a significantly larger user base. For example, MeetGroup (comprised of several apps) reported approximately 18 million monthly users compared to Clubhouse, which had approximately 600k total users as of December 2020.

We felt it was important to highlight these data points and are continuing to investigate these applications as well as monitor any potential instances of malicious actors exploiting this vulnerability. Given that Agora has released an updated SDK that fixes the call setup issues, vulnerable applications should have already switched to the secure calling SDK, thus protecting the sensitive audio and video call data as many claim to do. With that in mind, we decided to check back in with some of the Agora-based apps we previously investigated to confirm whether they had updated to the patched version. We were surprised to see many, as of February 18, 2020, still had not:

App Name Installs App Version App Version Date Updated Agora SDK
MeetMe 50,000,000+ 2/9/2021 Yes
LOVOO 50,000,000+ 93.0 2/15/2021 No
Plenty of Fish 50,000,000+ 2/5/2021 No
SKOUT 50,000,000+ 6.32.0 2/3/2021 Yes
Tagged 10,000,000+ 9.32.0 12/29/2020 No
GROWLr 1,000,000+ 16.1.1 2/11/2021 No
eharmony 5,000,000+ 8.16.2 2/5/2021 Yes
Clubhouse 2,000,000+ 2/16/2021 Yes
Practo 5,000,000+ 4.93 1/26/2021 No

With the context around censorship and basic privacy concerns, it will be interesting to see if these and many other apps using the vulnerable SDK update quickly, or even ever, and what kind of lasting effects these types of findings have on users’ trust and confidence in social media platforms.

For more on McAfee ATR’s research into the Agora SDK, please see our technical research blog.

For information on how users can protect themselves when using such apps, please see our consumer safety tips blog.

The post Beyond Clubhouse: Vulnerable Agora SDKs Still in Widespread Use appeared first on McAfee Blogs.

Researchers Follow the Breadcrumbs: The Latest Vulnerabilities in Windows’ Network Stack

9 February 2021 at 19:07
data breach
The concept of a trail of breadcrumbs in the offensive security community is nothing new; for many years, researchers on both sides of the ethical spectrum have followed the compass based on industry-wide security findings, often leading to groundbreaking discoveries in both legacy and modern codebases alike. This happened in countless instances, from Java to Flash to Internet Explorer and many more, often resulting in widespread findings and subsequent elimination or modification to large amounts of code. Over the last 12 months, we have noticed a similar trend in the analysis, discovery and disclosures of vulnerabilities in networking stacks. Starting with JSOF’s Ripple20, which we analyzed and released signatures for, a clear pattern emerged as researchers investigated anew the threat surfaces in the tcp/ip stacks deployed worldwide. Microsoft was no exception, of course running the Windows networking stack dating back to the earliest iterations of Windows, and frequently updated with new features and fixes.

In fact, looking back at just the last 8 months of Microsoft patches, we’ve tracked at least 25 significant vulnerabilities directly related to the Windows network stack. These have ranged from DNS to NTFS, SMB to NFS and recently, several tcp/ip bugs in fragmentation and packet reassembly for IPv4 and IPv6.

That brings us to this month’s patch Tuesday, which contains several more high-profile critical vulnerabilities in tcpip.sys. We’ll focus on three of these, including 2 marked as “remote code execution” bugs, which could lead to wormability if code execution is truly possible, and a persistent denial-of-service vulnerability which could cause a permanent Blue Screen of Death on the latest versions of Windows.

There are clear similarities between all 3, indicating both Microsoft and researchers external to Microsoft are highly interested in auditing this library, and are having success in weeding out a number of interesting bugs. The following is a short summary of each bug and the progress we have made to date in analyzing them.

What is CVE-2021-24086?
The first vulnerability analyzed in this set is a Denial-of-Service (DOS) attack. Generally, these types of bugs are rather uninteresting; however, a few can have enough of an impact that although an attacker can’t get code execution, they are well worth discussing. This is one of those few. One of the things that boost this vulnerability’s impact is the fact it is internet routable and many devices using IPv6 can be directly accessible over the internet, even when behind a router. It is also worth noting that the default Windows Defender Firewall configuration does not mitigate this attack. In a worst-case scenario, an attacker could spray this attack and put it on a continuous loop to potentially cause a “permanent” or persistent DOS to a wide range of systems.

This vulnerability exists when Windows’ tcpip.sys driver attempts to reassemble fragmented IPv6 packets. As a result, this attack requires many packets to be successful.  The root cause of this vulnerability is a NULL pointer dereference which occurs in Ipv6pReassembleDatagram. The crash occurs when reassembling a packet with around 0xffff bytes of extension headers.  It should be impossible to send a packet with that many bytes in the extension headers according to the RFC, however this is not considered in the Ipv6pReceiveFragments function when calculating the unfragmented length. Leveraging a proof-of-concept through the Microsoft MAPP program, McAfee was easily able to reproduce this bug, demonstrating it has the potential to be seen in the wild.

What is CVE-2021-24094?
This vulnerability is classified by Remote Code Execution (RCE), though our analysis thus far, code execution comes with unique challenges. Similar to CVE-2021-24086, this issue involves IPv6 packet reassembly by the Windows tcpip.sys driver. It is different from 24086 in that it doesn’t require a large packet with extension headers, and it is not a NULL pointer dereference. Instead, it is a dangling pointer which, if the right packet data is sprayed from an attacker over IPv6, will causes the pointer to be overwritten and reference an arbitrary memory location. When the data at the pointer’s target is accessed, it causes a page fault and thus a Blue Screen of Death (BSOD). Additionally, an attacker can create persistence of the DoS by continually pointing the attack at a victim machine.

While the reproduction of this issue causes crashes on the target in all reproductions so far, it’s unclear how easy it would be to force the pointer to a location that would cause valid execution without crashing. The pointer would need to point to a paged-in memory location that had already been written with additional data that could manipulate the IPv6 reassembly code, which would likely not come from this attack alone, but may require a separate attack to do so.

What is CVE-2021-24074?
CVE-2021-24074 is a potential RCE in tcpip.sys triggered during the reassembly of fragmented IPv4 packets in conjunction with a confusion of IPv4 IP Options. During reassembly, it is possible to have two fragments with different IP Options; this is against the IPv4 standard, but Windows will proceed further, while failing to perform proper sanity checks for the respective options. This type confusion can be leveraged to trigger an Out of Bounds (OOB) read and write by “smuggling” an IP option Loose source and record route (LSRR) with invalid parameters. This option is normally meant to specify the route a packet should take. It has a variable length, starts with a pointer field, and is followed by a list of IP addresses to route the packet through.

By leveraging the type confusion, we have an invalid pointer field that will point beyond the end of the routing list provided in the packet. When the routing function Ipv4pReceiveRoutingHeader looks up the next hop for the packet, it will OOB read this address (as a DWORD) and perform a handful of checks on it. If these checks are successful, the IP stack will attempt to route the packet to its next hop by copying the original packet and then writing its own IP address in the record route. Because this write relies on the same invalid pointer value as before, this turns out to be an OOB write (beyond the end of the newly allocated packet). The content of this OOB write is the IP address of the target machine represented as a DWORD (thus, not controlled by the attacker).

Microsoft rates this bug as “Exploitation more likely”, however exploitation might not be as straightforward as it sounds. For an attack to succeed, one would have to groom the kernel heap to place a certain value to be read during the OOB read, and then make it so the OOB write would corrupt something of interest. Likely, a better exploitation primitive would need to be established first in order to successfully exploit the bug. For instance, leveraging the OOB write to corrupt another data structure that could lead to information disclosure and/or a write-what-where scenario.

From a detection standpoint, the telltale signs of an active exploitation would be fragmented packets whose IP Options vary between fragments. For instance, the first fragment would not contain an LSRR option, while the second fragment would. This would likely be accompanied by a heavy traffic meant to shape the kernel heap.

Similarities and Impact Assessment
There are obvious similarities between all three of these vulnerabilities. Each is present in the tcpip.sys library, responsible for parsing IPv4 and IPv6 traffic. Furthermore, the bugs all deal with packet reassembly and the RCE vulnerabilities leverage similar functions for IPv4 and IPv6 respectively. Given a combination of public and Microsoft-internal attribution, it’s clear that researchers and vendor alike are chasing down the same types of bugs. Whenever we see vulnerabilities in network stacks or Internet-routed protocols, we’re especially interested to determine difficulty of exploitation, wormability, and impact. For vulnerabilities such as the RCEs above, a deep dive is essential to understand the likelihood of these types of flaws being built into exploit kits or used in targeted attacks and are prime candidates for threat actors to weaponize. Despite the real potential for harm, the criticality of these bugs is somewhat lessened by a higher bar to exploitation and the upcoming patches from Microsoft. We do expect to see additional vulnerabilities in the TCP/IP stack and will continue to provide similar analysis and guidance. As it is likely to take some time for threat actors to integrate these vulnerabilities in a meaningful way, the best course of action, as always, is widespread mitigation via patching.

The post Researchers Follow the Breadcrumbs: The Latest Vulnerabilities in Windows’ Network Stack appeared first on McAfee Blogs.

McAfee ATR Launches Education-Inspired Capture the Flag Contest!

27 January 2021 at 16:00

McAfee’s Advanced Threat Research team just completed its second annual capture the flag (CTF) contest for internal employees. Based on tremendous internal feedbackwe’ve decided to open it up to the public, starting with a set of challenges we designed in 2019.  

We’ve done our best to minimize guesswork and gimmicks and instead of flashy graphics and games, we’ve distilled the kind of problems we’ve encountered many times over the years during our research projects. Additionally, as this contest is educational in nature, we won’t be focused as much on the winners of the competition. The goal is for anyone and everyone to learn something new. However, we will provide a custom ATR challenge coin to the top 5 teams (one coin per team). All you need to do is score on 2 or more challenges to be eligible. When registering for the contest, make sure to use a valid email address so we can contact you.  

The ATR CTF will open on Friday, February 5th at 12:01pm PST and conclude on Thursday, February 18th, at 11:59pm PST.  

Click Here to Register! 

​​​​​​​If you’ve never participated in a CTF before, the concept is simple. You will: 

  • Choose the type of challenge you want to work on, 
  • Select a difficulty level by point value, 
  • Solve the challenge to find a ‘flag,’ and 
  • Enter the flag for the corresponding points.​​​​​

NOTE: The format of all flags is ATR[], placing the flag,  between the square brackets. For example: ATR[1a2b3c4d5e]. The flag must be submitted in full, including the ATR and square bracket parts.

The harder the challenge, the higher the points!  Points range from 100 to 500. All CTF challenges are designed to practice real-world security concepts, and this year’s categories include: 

  • Reverse engineering 
  • Exploitation 
  • Web 
  • Hacking Tools 
  • Crypto 
  • RF (Radio Frequency) 
  • Mobile 
  • Hardware

The contest is set up to allow teams as groups or individuals. If you get stuck, a basic hint is available for each challenge, but be warned – it will cost ​​​​​​​you points to access the hint and should only be used as a last resort.  

Read before hacking: CTF rules and guidelines 

McAfee employees are not eligible for prizes in the public competition but are welcome to compete. 

When registering, please use a valid email address, for any password resets and to be contacted for prizes. We will not store or save any email addresses or contact you for any non-contest related reasons.

Please wait until the contest ends to release any solutions publicly. 


No cooperation between teams with independent accounts. Sharing of keys or providing/revealing hints to other teams is cheating, please help us keep this contest a challenge for all! 

Attacking the Platform 

Please refrain from attacking the competition infrastructure. If you experience any difficulties with the infrastructure itself, questions can be directed to the ATR team using the email in the Contact Us section. ATR will not provide any additional hints, feedback, or clues. This email is only for issues that might arise, not related to individual challenges. 


Absolutely no sabotaging of other competing teams, or in any way hindering their independent progress. 

Brute Forcing 

No brute forcing of challenge flag/ keys against the scoring site is accepted or required to solve the challenges. You may perform brute force attacks if necessary, on your own endpoint to determine a solution if needed. If you’re not sure what constitutes a brute force attack, please feel free to contact us. 


DoSing the CapturetheFlag (CTF) platform or any of the challenges is forbidden

Additional rules are posted within the contest following login and should be reviewed by all contestants prior to beginning.

Many of these challenges are designed with Linux end-users in mind. However, if you are a Windows user, Windows 10 has a Linux subsystem called ‘WSL’ that can be useful, or a Virtual Machine can be configured with any flavor of Linux desired and should work for most purposes.​​​​​​​

​​​​​​​Happy hacking! 

Looking for a little extra help? 

Find a list of useful tools and techniques for CTF competitions. While it’s not exhaustive or specifically tailored to this contest, it should be a useful starting point to learn and understand tools required for various challenges. 

Contact Us 

While it may be difficult for us to respond to emails, we will do our best – please use this email address to reach us with infrastructure problems, errors with challenges/flag submissions, etc. We are likely unable to respond to general questions on solving challenges. 

[email protected] 

How much do you know about McAfee’s ​​​​​​​industry-leading research team? 

ATR is a team of security researchers that deliver cutting-edge vulnerability and malware research, red teaming, operational intelligence and more! To read more about the team and some of its highlighted research, please follow this link to the ATR website. 

General Release Statement 

By participating in the contest, you agree to be bound to the Official Rules and to release McAfee and its employees, and the hosting organization from any and all liability, claims or actions of any kind whatsoever for injuries, damages or losses to persons and property which may be sustained in connection with the contest. You acknowledge and agree that McAfee et al is not responsible for technical, hardware or software failures, or other errors or problems which may occur in connection with the contest.  By participating you allow us to publish your name.  The collection and use of personal information from participants will be governed by the McAfee Private Notice.  

The post McAfee ATR Launches Education-Inspired Capture the Flag Contest! appeared first on McAfee Blogs.

CVE-2020-16898: “Bad Neighbor”

13 October 2020 at 17:06

CVE-2020-16898: “Bad Neighbor”

CVSS Score: 8.8

Vector: CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C

Today, Microsoft announced a critical vulnerability in the Windows IPv6 stack, which allows an attacker to send maliciously crafted packets to potentially execute arbitrary code on a remote system. The proof-of-concept shared with MAPP (Microsoft Active Protection Program) members is both extremely simple and perfectly reliable. It results in an immediate BSOD (Blue Screen of Death), but more so, indicates the likelihood of exploitation for those who can manage to bypass Windows 10 and Windows Server 2019 mitigations. The effects of an exploit that would grant remote code execution would be widespread and highly impactful, as this type of bug could be made wormable. For ease of reference, we nicknamed the vulnerability “Bad Neighbor” because it is located within an ICMPv6 Neighbor Discovery “Protocol”, using the Router Advertisement type.

Vulnerability Details
A remote code execution vulnerability exists when the Windows TCP/IP stack improperly handles ICMPv6 Router Advertisement packets that use Option Type 25 (Recursive DNS Server Option) and a length field value that is even. In this Option, the length is counted in increments of 8 bytes, so an RDNSS option with a length of 3 should have a total length of 24 bytes. The option itself consists of five fields: Type, Length, Reserved, Lifetime, and Addresses of IPv6 Recursive DNS Servers. The first four fields always total 8 bytes, but the last field can contain a variable number of IPv6 addresses, which are 16 bytes each. As a result, the length field should always be an odd value of at least 3, per RFC 8106:

When an IPv6 host receives DNS options (i.e., RDNSS and DNSSL
options) through RA messages, it processes the options as follows:

   o  The validity of DNS options is checked with the Length field;
      that is, the value of the Length field in the RDNSS option is
      greater than or equal to the minimum value (3) and satisfies the
      requirement that (Length - 1) % 2 == 0.

When an even length value is provided, the Windows TCP/IP stack incorrectly advances the network buffer by an amount that is 8 bytes too few. This is because the stack internally counts in 16-byte increments, failing to account for the case where a non-RFC compliant length value is used. This mismatch results in the stack interpreting the last 8 bytes of the current option as the start of a second option, ultimately leading to a buffer overflow and potential RCE.

It is likely that a memory leak or information disclosure bug in the Windows kernel would be required in order to build a full exploit chain for this vulnerability. Despite this, we expect to see working exploits in the very near future.

Threat Surface
The largest impact here will be to consumers on Windows 10 machines, though with Windows Updates the threat surface is likely to be quickly minimized. While shouldn’t be counted on as a definitive source, our best queries put the number of Windows Server 2019 machines with IPv6 addresses is in the hundreds, not exceeding approximately 1000. This is likely because most servers are behind firewalls or hosted by Cloud Service Providers (CSPs) and not reachable directly via Shodan scans.

We believe this vulnerability can be detected with a simple heuristic that parses all incoming ICMPv6 traffic, looking for packets with an ICMPv6 Type field of 134 – indicating Router Advertisement – and an ICMPv6 Option field of 25 – indicating Recursive DNS Server (RDNSS). If this RDNSS option also has a length field value that is even, the heuristic would drop or flag the associated packet, as it is likely part of a “Bad Neighbor” exploit attempt.

Patching is always the first and most effective course of action. If this is not possible, the best mitigation is disabling IPv6, either on the NIC or at the perimeter of the network by dropping ICMPv6 traffic if it is non-essential. Additionally, ICMPv6 Router Advertisements can be blocked or dropped at the network perimeter. Windows Defender and Windows Firewall fail to block the proof-of-concept when enabled. It is unknown yet if this attack can succeed by tunneling the ICMPv6 traffic over IPv4 using technologies like 6to4 or Teredo. Our efforts to repeat the attack in this manner have not been successful to date.

For those McAfee customers who are unable to deploy the Windows patch, the following Network Security Platform (NSP) signatures will provide a virtual patch against attempted exploitation of this vulnerability, as well as a similar vulnerability (CVE-2020-16899). Unlike “Bad Neighbor”, the impact of CVE-2020-16899 is limited to denial-of-service in the form of BSoD.

NSP Attack ID: 0x40103a00 – ICMP: Windows IPv6 Stack Elevation of Privilege Vulnerability (CVE-2020-16898)
NSP Attack ID: 0x40103b00 – ICMP: Windows Function Discovery SSDP Provider Elevation of Privilege Vulnerability (CVE-2020-16899)

Additionally, we are releasing Suricata rules to detect potential exploitation of these vulnerabilities. Due to limitations in open source tools such as Snort and Suricata, we found that implementing the minimal detection logic described earlier required combining Suricata with its built-in Lua script parser. We have hosted the rules and Lua scripts at our public GitHub under CVE-2020-16898 and CVE-2020-16899 respectively. Although we have confirmed that the rules correctly detect use of the proof-of-concepts, they should be thoroughly vetted in your environment prior to deployment to avoid risk of any false positives.

The post CVE-2020-16898: “Bad Neighbor” appeared first on McAfee Blogs.

Dopple-ganging up on Facial Recognition Systems

5 August 2020 at 16:01

Co-authored with Jesse Chick, OSU Senior and Former McAfee Intern, Primary Researcher.

Special thanks to Dr. Catherine Huang, McAfee Advanced Analytics Team
Special thanks to Kyle Baldes, Former McAfee Intern

“Face” the Facts

There are 7.6 Billion people in the world. That’s a huge number! In fact, if we all stood shoulder to shoulder on the equator, the number of people in the world would wrap around the earth over 86 times! That’s just the number of living people today; even adding in the history of all people for all time, you will never find two identical human faces. In fact, in even some of the most similar faces recorded (not including twins) it is quite easy to discern multiple differences. This seems almost impossible; it’s just a face, right? Two eyes, a nose, a mouth, ears, eyebrows and potentially other facial hair. Surely, we would have run into identical unrelated humans by this point. Turns out, there’s SO much more to the human face than this which can be more subtle than we often consider; forehead size, shape of the jaw, position of the ears, structure of the nose, and thousands more extremely minute details.

You may be questioning the significance of this detail as it relates to McAfee, or vulnerability research. Today, we’ll explore some work undertaken by McAfee Advanced Threat Research (ATR) in the context of data science and security; specifically, we looked at facial recognition systems and whether they were more, or less susceptible to error than we as human beings.

Look carefully at the four images below; can you spot which of these is fake and which are real?

StyleGAN images

The answer may surprise you; all four images are completely fake – they are 100% computer-generated, and not just parts of different people creativally superimposed. An expert system known as StyleGAN generated each of these, and millions more, with varying degrees of photorealism, from scratch.

This impressive technology is equal parts revolutions in data science and emerging technology that can compute faster and cheaper at a scale we’ve never seen before. It is enabling impressive innovations in data science and image generation or recognition, and can be done in real time or near real time. Some of the most practical applications for this are in the field of facial recognition; simply put, the ability for a computer system to determine whether two images or other media represent the same person or not. The earliest computer facial recognition technology dates back to the 1960s, but until recently, has either been cost-ineffective, false positive or false negative prone, or too slow and inefficient for the intended purpose.

The advancements in technology and breakthroughs in Artificial Intelligence and Machine Learning have enabled several novel applications for facial recognition. First and foremost, it can be used as a highly reliable authentication mechanism; an outstanding example of this is the iPhone. Beginning with the iPhone X in 2017, facial recognition was the new de facto standard for authenticating a user to their mobile device. While Apple uses advanced features such as depth to map the target face, many other mobile devices have implemented more standard methods based on the features of the target face itself; things we as humans see as well, including placement of eyes, width of the nose, and other features that in combination can accurately identify a single user. More simplistic and standard methods such as these may inherently suffer from security limitations relative to more advanced capabilities, such as the 3D camera capture. In a way, this is the whole point; the added complexity of depth information is what makes pixel-manipulation attacks impossible.

Another emerging use case for facial recognition systems is for law enforcement. In 2019, the Metropolitan Police in London announced the rollout of a network of cameras designed to aid police in automating the identification of criminals or missing persons. While widely controversial, the UK is not alone in this initiative; other major cities have piloted or implemented variants of facial recognition with or without the general population’s consent. In China, many of the trains and bus systems leverage facial recognition to identify and authenticate passengers as they board or unboard. Shopping centers and schools across the country are increasingly deploying similar technology.

More recently, in light of racial profiling and racial bias demonstrated repeatedly in facial recognition AI, IBM announced that it would eliminate its facial recognition programs given the way it could be used in law enforcement. Since then, many other major players in the facial recognition business have suspended or eliminated their facial recognition programs. This may be at least partially based on a high profile “false positive” case in which authorities errantly based an arrest of an individual on an incorrect facial recognition match of a black man named Robert Williams. The case is known as the country’s first wrongful arrest directly resulting from facial recognition technology.

Facial recognition has some obvious benefits of course, and this recent article details the use of facial recognition technology in China to track down and reunite a family many years after an abduction. Despite this, it remains a highly polarizing issue with significant privacy concerns, and may require significant further development to reduce some of the inherent flaws.

Live Facial Recognition for Passport Validation

Our next use case for facial recognition may hit closer to home than you realize. Multiple airports, including many in the United States, have deployed facial recognition systems to aid or replace human interaction for passport and identity verification. In fact, I was able to experience one of these myself in the Atlanta airport in 2019. It was far from ready, but travellers can expect to see continued rollouts of this across the country. In fact, based on the global impact COVID-19 has had on travel and sanitization, we are observing an unprecedented rush to implement touchless solutions such as biometrics. This is of course being done from a responsibility standpoint, but also from an airlines and airport profitability perspective. If these two entities can’t convince travelers that their travel experience is low-risk, many voluntary travelers will opt to wait until this assurance is more solid. This article expands on the impact Coronavirus is having on the fledgling market use of passport facial recognition, providing specific insight into Delta and United Airlines’ rapid expansion of the tech into new airports immediately, and further testing and integration in many countries around the world. While this push may result in less physical contact and fewer infections, it may also have the side-effect of exponentially increasing the attack surface of a new target.

The concept of passport control via facial recognition is quite simple. A camera takes a live video and/or photos of your face, and a verification service compares it to an already-existing photo of you, collected earlier. This could be from a passport or a number of other sources such as the Department of Homeland Security database. The “live” photo is most likely processed into a similar format (image size, type of image) as the target photo, and compared. If it matches, the passport holder is authenticated. If not, an alternate source will be checked by a human operator, including boarding passes and forms of ID.

As vulnerability researchers, we need to be able to look at how things work; both the intended method of operation as well as any oversights. As we reflected on this growing technology and the extremely critical decisions it enabled, we considered whether flaws in the underlying system could be leveraged to bypass the target facial recognition systems. More specifically, we wanted to know if we could create “adversarial images” in a passport-style format, that would be incorrectly classified as a targeted individual. (As an aside, we performed related attacks in both digital and physical mediums against image recognition systems, including research we released on the MobilEye camera deployed in certain Tesla vehicles.)

The conceptual attack scenario here is simple. We’ll refer to our attacker as Subject A, and he is on the “no-fly” list – if a live photo or video of him matches a stored passport image, he’ll immediately be refused boarding and flagged, likely for arrest. We’ll assume he’s never submitted a passport photo. Subject A (AKA Jesse), is working together with Subject B (AKA Steve), the accomplice, who is helping him to bypass this system. Jesse is an expert in model hacking and generates a fake image of Steve through a system he builds (much more on this to come). The image has to look like Steve when it’s submitted to the government, but needs to verify Jesse as the same person as the adversarial fake “Steve” in the passport photo. As long as a passport photo system classifies a live photo of Jesse as the target fake image, he’ll be able to bypass the facial recognition.

If this sounds far-fetched to you, it doesn’t to the German government. Recent policy in Germany included verbiage to explicitly disallow morphed or computer-generated combined photos. While the techniques discussed in this link are closely related to this, the approach, techniques and artifacts created in our work vary widely. For example, the concepts of face morphing in general are not novel ideas anymore; yet in our research, we use a more advanced, deep learning-based morphing approach, which is categorically different from the more primitive “weighted averaging” face morphing approach.

Over the course of 6 months, McAfee ATR researcher and intern Jesse Chick studied state-of-the-art machine learning algorithms, read and adopted industry papers, and worked closely with McAfee’s Advanced Analytics team to develop a novel approach to defeating facial recognition systems. To date, the research has progressed through white box and gray box attacks with high levels of success – we hope to inspire or collaborate with other researchers on black box attacks and demonstrate these findings against real world targets such as passport verification systems with the hopes of improving them.

The Method to the Madness

The term GAN is an increasingly-recognized acronym in the data science field. It stands for Generative Adversarial Network and represents a novel concept using one or more “generators” working in tandem with one or more “discriminators.” While this isn’t a data science paper and I won’t go into great detail on GAN, it will be beneficial to understand the concept at a high level. You can think of GAN as a combination of an art critic and an art forger. An art critic must be capable of determining whether a piece of art is real or forged, and of what quality the art is. The forger of course, is simply trying to create fake art that looks as much like the original as possible, to fool the critic. Over time, the forger may outwit the critic, and at other times the opposite may hold true, yet ultimately, over the long run, they will force each other to improve and adapt their methods. In this scenario, the forger is the “generator” and the art critic is the “discriminator.” This concept is analogous to GAN in that the generator and discriminator are both working together and also opposing each other – as the generator creates an image of a face, for example, the discriminator determines whether the image generated actually looks like a face, or if it looks like something else. It rejects the output if it is not satisfied, and the process starts over. This is repeated in the training phase for as long of a time as it takes for the discriminator to be convinced that the generator’s product is high enough quality to “meet the bar.”

One such implementation we saw earlier, StyleGAN, uses these exact properties to generate the photorealistic faces shown above. In fact, the research team tested StyleGAN, but determined it was not aligned with the task we set out to achieve: generating photorealistic faces, but also being able to easily implement an additional step in face verification. More specifically, its sophisticated and niche architecture would have been highly difficult to harness successfully for our purpose of clever face-morphing. For this reason, we opted to go with a relatively new but powerful GAN framework known as CycleGAN.


CycleGAN is a GAN framework that was released in a paper in 2017. It represents a GAN methodology that uses two generators and two discriminators, and in its most basic sense, is responsible for translating one image to another through the use of GAN.

Image of zebras translated to horses via CycleGAN

There are some subtle but powerful details related to the CycleGAN infrastructure. We won’t go into depth on these, but one important concept is that CycleGAN uses higher level features to translate between images. Instead of taking random “noise” or “pixels” in the way StyleGAN translates into images, this model uses more significant features of the image for translation (shape of head, eye placement, body size, etc…). This works very well for human faces, despite the paper not specifically calling out human facial translation as a strength.

Face Net and InceptionResnetV1

While CycleGAN is an novel use of the GAN model, in and of itself it has been used for image to image translation numerous times. Our facial recognition application facilitated the need for an extension of this single model, with an image verification system. This is where FaceNet came into play. The team realized that not only would our model need to accurately create adversarial images that were photorealistic, it would also need to be verified as the original subject. More on this shortly. FaceNet is a face recognition architecture that was developed by Google in 2015, and was and perhaps still is considered state of the art in its ability to accurately classify faces. It uses a concept called facial embeddings to determine mathematical distances between two faces in a dimension. For the programmers or math experts, 512 dimensional space is used, to be precise, and each embedding is a 512 dimensional list or vector. To the lay person, the less similar the high level facial features are, the further apart the facial embeddings are. Conversely, the more similar the facial features, the closer together these faces are plotted. This concept is ideal for our use of facial recognition, given FaceNet operates against high level features of the face versus individual pixels, for example. This is a central concept and a key differentiator between our research and “shallow”adversarial image creation a la more traditionally used FGSM, JSMA, etc. Creating an attack that operates at the level of human-understandable features is where this research breaks new ground.

One of the top reasons for FaceNet’s popularity is that is uses a pre-trained model with a data set trained on hundreds of millions of facial images. This training was performed using a well-known academic/industry-standard dataset, and these results are readily available  for comparison. Furthermore, it achieved very high published accuracy (99.63%) when used on a set of 13,000 random face images from a benchmark set of data known as LFW (Labeled Faces in the Wild). In our own in-house evaluation testing, our accuracy results were closer to 95%.

Ultimately, given our need to start with a white box to understand the architecture, the solution we chose was a combination of CycleGAN and an open source FaceNet variant architecture known as InceptionResnet version 1. The ResNet family of deep neural networks uses learned filters, known as convolutions, to extract high-level information from visual data. In other words, the role of deep learning in face recognition is to transform an abstract feature from the image domain, i.e. a subject’s identity, into a domain of vectors (AKA embeddings) such that they can be reasoned about mathematically. The “distance” between the outputs of two images depicting the same subject should be mapped to a similar region in the output space, and two very different regions for input depicting different subjects. It should be noted that the success or failure of our attack is contingent on its ability to manipulate the distance between these face embeddings. To be clear, FaceNet is the pipeline consisting of data pre-processing, Inception ResNet V1, and data separation via a learned distance threshold.


Whoever has the most data wins. This truism is especially relevant in the context of machine learning. We knew we would need a large enough data set to accurately train the attack generation model, but we guessed that it would be smaller than many other use cases. This is because given our goal was simply to take two people, subject A (Jesse) and subject B (Steve) below and minimize the “distance” between the two face embeddings produced when inputted into FaceNet, while preserving a misclassification in either direction. In other words, Jesse needed to look like Jesse in his passport photo, and yet be classified as Steve, and vice versa. We’ll describe facial embeddings and visualizations in detail shortly.

The training was done on a set of 1500 images of each of us, captured from live video as stills. We provided multiple expressions and facial gestures that would enrich the training data and accurately represent someone attempting to take a valid passport photo.

The research team then integrated the CycleGAN + FaceNet architecture and began to train the model.

As you can see from the images below, the initial output from the generator is very rough – these certainly look like human beings (sort of), but they’re not easily identifiable and of course have extremely obvious perturbations, otherwise known as “artifacts.”

However, as we progress through training over dozens of cycles, or epochs, a few things are becoming more visually apparent. The faces begin to clean up some of the abnormalities while simultaneously blending features of both subject A and subject B. The (somewhat frightening) results look something like this:

Progressing even further in the training epochs, and the discriminator is starting to become more satisfied with the generator’s output. Yes, we’ve got some detail to clean up, but the image is starting to look much more like subject B.

A couple hundred training epochs in, and we are producing candidates that would meet the bar for this application; they would pass as valid passport photos.

Fake image of Subject B

Remember, that with each iteration through this training process, the results are systematically fed into the facial recognition neural network and classified as Subject A or Subject B. This is essential as any photo that doesn’t “properly misclassify” as the other, doesn’t meet one of the primary objectives and must be rejected. It is also a novel approach as there are very few research projects which combine a GAN and an additional neural network in a cohesive and iterative approach like this.

We can see visually above that the faces being generated at this point are becoming real enough to convince human beings that they are not computer-generated. At the same time, let’s look behind the curtain and see some facial embedding visualizations which may help clarify how this is actually working.

To further understand facial embeddings, we can use the following images to visualize the concept. First, we have the images used for both training and generation of images. In other words, it contains real images from our data set and fake (adversarial) generated images as shown below:

Model Images (Training – Real_A & Real_B) – Generated (Fake_B & Fake_A)

This set of images is just one epoch of the model in action – given the highly realistic fake images generated here, it is not surprisingly a later epoch in the model evaluation.

To view these images as mathematical embeddings, we can use a visualization representing them on a multidimensional plane, which can be rotated to show the distance between them. It’s much easier to see that this model represents a cluster of “Real A” and “Fake B” on one side, and a separate cluster of “Real B” and “Fake A” on the other. This is the ideal attack scenario as it clearly shows how the model will confuse the fake image of the accomplice with the real image of the attacker, our ultimate test.

White Box and Gray Box Application

With much of machine learning, the model must be both effectively trained as well as able to reproduce and replicate results in future applications. For example, consider a food image classifier; its job being to correctly identify and label the type of food it sees in an image. It must have a massive training set so that it recognizes that a French Fry is different than a crab leg, but it also must be able to reproduce that classification on images of food it’s never seen before with a very high accuracy. Our model is somewhat different in that it is trained specifically on two people only (the adversary and the accomplice), and its job is done ahead of time during training. In other words, once we’ve generated a photorealistic image of the attacker that is classified as the accomplice, the model’s job is done. One important caveat is that it must work reliably to both correctly identify people and differentiate people, much like facial recognition would operate in the real world.

The theory behind this is based on the concept of transferability; if the models and features chosen in the development phase (called white box, with full access to the code and knowledge of the internal state of the model and pre-trained parameters) are similar enough to the real-world model and features (black box, no access to code or classifier) an attack will reliably transfer – even if the underlying model architecture is vastly different. This is truly an incredible concept for many people, as it seems like an attacker would need to understand every feature, every line of code, every input and output, to predict how a model will classify “adversarial input.” After all, that’s how classical software security works for the most part. By either directly reading or reverse engineering a piece of code, an attacker can figure out the precise input to trigger a bug. With model hacking (often called adversarial machine learning), we can develop attacks in a lab and transfer them to black box systems. This work, however, will take us through white box and gray box attacks, with possible future work focusing on black box attacks against facial recognition.

As mentioned earlier, a white box attack is one that is developed with full access to the underlying model – either because the researcher developed the model, or they are using an open source architecture. In our case, we did both to identify the ideal combination discussed above, integrating CycleGAN with various open source facial recognition models. The real Google FaceNet is proprietary, but it has been effectively reproduced by researchers as open source frameworks that achieve very similar results, hence our use of Inception Resnet v1. We call these versions of the model “gray box” because they are somewhere in the middle of white box and black box.

To take the concepts above from theory to the real world, we need to implement a physical system that emulates a passport scanner. Without access to the actual target system, we’ll simply use an RGB camera, such as the external one you might see on desktops in a home or office. The underlying camera is likely quite similar to the technology used by a passport photo camera. There’s some guesswork needed to determine what the passport camera is doing, so we take some educated liberties. The first thing to do is programmatically capture every individual frame from the live video and save them in memory for the duration of their use. After that, we apply some image transformations, scaling them to a smaller size and appropriate resolution of a passport-style photo. Finally, we pass each frame to the underlying pretrained model we built and ask it to determine whether the face it is analyzing is Subject A (the attacker), or Subject B (the accomplice). The model has been trained on enough images and variations of both that even changes in posture, position, hair style and more will still cause a misclassification. It’s worth noting that in this attack method, the attacker and accomplice are working together and would likely attempt to look as similar as possible to the original images in the data set the model is trained, as it would increase the overall misclassification confidence.

The Demos

The following demo videos demonstrate this attack using our gray box model. Let’s introduce the 3 players in these videos. In all three, Steve is the attacker now, Sam is our random test person, and Jesse is our accomplice. The first will show the positive test.

Positive Test:

This uses a real, non-generated image on the right side of the screen of Steve (now acting as our attacker). Our random test person (Sam), first stands in front of the live “passport verification camera” and is compared against the real image of Steve. They should of course be classified as different. Now Steve stands in front of the camera and the model correctly identifies him against his picture, taken from the original and unaltered data set. This proves the system can correctly identify Steve as himself.

Negative Test:

Next is the negative test, where the system tests Sam against a real photo of Jesse. He is correctly classified as different, as expected. Then Steve stands in front of the system and confirms the negative test as well, showing that the model correctly differentiates people in non-adversarial conditions.

Adversarial Test:

Finally, in the third video, Sam is evaluated against an adversarial, or fake image of Jesse, generated by our model. Since Sam was not part of the CycleGAN training set designed to cause misclassification, he is correctly shown as different again. Lastly, our attacker Steve stands in front of the live camera and is correctly misclassified as Jesse (now the accomplice). Because the model was trained for either Jesse or Steve to be the adversarial image, in this case we chose Jesse as the fake/adversarial image.

If a passport-scanner were to replace a human being completely in this scenario, it would believe it had just correctly validated that the attacker was the same person stored in the passport database as the accomplice. Given the accomplice is not on a no-fly list and does not have any other restrictions, the attacker can bypass this essential verification step and board the plane. It’s worth noting that a human being would likely spot the difference between the accomplice and attacker, but this research is based off of the inherent risks associated with reliance on AI and ML alone, without providing defense-in-depth or external validation, such as a human being to validate.

Positive Test Video – Confirming Ability to Recognize a Person as Himself

Negative Test Video – Confirming Ability to Tell People Apart

Adversarial Test Video – Confirming Ability to Misclassify with Adversarial Image

What Have we Learned?

Biometrics are an increasingly relied-upon technology to authenticate or verify individuals and are effectively replacing password and other potentially unreliable authentication methods in many cases. However, the reliance on automated systems and machine learning without considering the inherent security flaws present in the mysterious internal mechanics of face-recognition models could provide cyber criminals unique capabilities to bypass critical systems such as automated passport enforcement. To our knowledge, our approach to this research represents the first-of-its-kind application of model hacking and facial recognition. By leveraging the power of data science and security research, we look to work closely with vendors and implementors of these critical systems to design security from the ground up, closing the gaps that weaken these systems. As a call to action, we look to the community for a standard by which can reason formally about the reliability of machine learning systems in the presence of adversarial samples. Such standards exist in many verticals of computer security, including cryptography, protocols, wireless radio frequency and many more. If we are going to continue to hand off critical tasks like authentication to a black box, we had better have a framework for determining acceptable bounds for its resiliency and performance under adverse conditions.

For more information on research efforts by McAfee Advanced Threat Research, please follow our blog or visit our website.

The post Dopple-ganging up on Facial Recognition Systems appeared first on McAfee Blogs.

Ripple20 Critical Vulnerabilities – Detection Logic and Signatures

5 August 2020 at 13:00

This document has been prepared by McAfee Advanced Threat Research in collaboration with JSOF who discovered and responsibly disclosed the vulnerabilities. It is intended to serve as a joint research effort to produce valuable insights for network administrators and security personnel, looking to further understand these vulnerabilities to defend against exploitation. The signatures produced here should be thoroughly considered and vetted in staging environments prior to being used in production and may benefit from specific tuning to the target deployment. There are technical limitations to this work, including the fact that more complex methods of detection might be required to detect these vulnerabilities. For example, multiple layers of encapsulation may obfuscate the exploitation of the flaws and increase the difficulty of detection.

We have also provided packet captures taken from the vulnerability Proof-of-Concepts as artifacts for testing and deployment of either the signatures below or customized signatures based on the detection logic. Signatures and Lua Scripts are located on ATR’s Github page, as well as inline and in the appendix of this document respectively.

As of this morning (August 5th), JSOF has presented additional technical detail and exploitation analysis at BlackHat 2020, on the two most critical vulnerabilities in DNS.

The information provided herein is subject to change without notice, and is provided “AS IS”, with all faults, without guarantee or warranty as to the accuracy or applicability of the information to any specific situation or circumstance and for use at your own risk. Additionally, we cannot guarantee any performance or efficacy benchmarks for any of the signatures.

Integer Overflow in tfDnsExpLabelLength Leading to Heap Overflow and RCE

CVE: CVE-2020-11901 (Variant 1)
Protocol(s): DNS over UDP (and likely DNS over TCP)
Port(s): 53

Vulnerability description:
In the Treck stack, DNS names are calculated via the function tfDnsExpLabelLength. A bug exists in this function where the computation is performed using an unsigned short, making it possible to overflow the computed value with a specially constructed DNS response packet. Since tfDnsExpLabelLength computes the full length of a DNS name after it is decompressed, it is possible to induce an overflow using a DNS packet far smaller than 216 bytes. In some code paths, tfGetRawBuffer is called shortly after tfDnsExpLabelLength, allocating a buffer on the heap where the DNS name will be stored using the size computed by tfDnsExpLabelLength, thus leading to a heap overflow and potential RCE.

While newer versions of the Treck stack will stop copying the DNS name into the buffer as soon as a character that isn’t alphanumeric or a hyphen is reached, older versions do not have this restriction and further use predictable transaction IDs for DNS queries, making this vulnerability easier to exploit.

Limitations or special considerations for detection:
Ideally, detection logic for this vulnerability would involve independently computing the uncompressed length of all DNS names contained within incoming DNS responses. Unfortunately, this may be computationally expensive for a device to perform for every incoming DNS response, especially since each one may contain many DNS names. Instead, we must rely on a combination of heuristics.

Furthermore, it is currently unclear whether exercising this vulnerability is possible when using EDNS(0) or DNS over TCP. We recommend assuming it is possible for the purposes of implementing detection logic.  During our testing, an inconsistency in how Suricata handled DNS over TCP was discovered – in some cases it was correctly identified as DNS traffic and in other cases, it was not. Consequently, two rules have been created to determine the size of DNS over TCP traffic. The second rule uses the TCP primitive instead of the DNS primitive; however, the second rule will only be evaluated if not flagged by the first rule.

Because the Suricata rule in dns_invalid_size.rules uses the DNS responses’ EDNS UDP length, which may be controlled by the attacker, a second upper limit of 4096 bytes is enforced.

Recommended detection criteria:

  • The device must be capable of processing DNS traffic and matching responses to their corresponding requests.
  • The device must be capable of identifying individual DNS names within individual DNS packets.
  • The device should flag any DNS responses whose size exceeds what is “expected”. The expected size depends on the type of DNS packet sent:
      • For DNS over TCP, the size should not exceed the value specified in the first two bytes of the TCP payload.
      • For DNS over UDP with EDNS(0), the size should not exceed the value negotiated in the request, which is specified in the CLASS field of the OPT RR, if present.
      • For DNS over UDP without EDNS(0), the size should not exceed 512 bytes.
      • These are all checked in dns_invalid_size.rules, which invokes either dns_size.lua or dns_tcp_size.lua for the logic.
  • The device should flag DNS responses containing DNS names exceeding 255 bytes (prior to decompression).
      • This is checked in dns_invalid_name.rules, which invokes dns_invalid_name.lua for the logic.
  • The device should flag DNS responses containing DNS names comprised of characters besides a-z, A-Z, 0-9, “-”, “_”, and “*”.
      • This is also checked in dns_invalid_name.rules, which invokes dns_invalid_name.lua for the logic.
  • The device should flag DNS responses containing a large number of DNS compression pointers, particularly pointers one after the other. The specific tolerance will depend on the network.
      • The device should count all labels starting with the bits 0b10, 0b01, or 0b11 against this pointer total, as vulnerable versions of the Treck stack (incorrectly) classify all labels where the first two bits aren’t 0b00 as compression pointers. In the Lua script, we treat any value above 63 (0x3F) as a pointer for this reason, as any value in that range will have at least one of these bits set.
      • The specific thresholds were set to 40 total pointers in a single DNS packet or 4 consecutive pointers for our implementation of this rule. These values were chosen since they did not seem to trigger any false positives in a very large test PCAP but should be altered as needed to suit typical traffic for the network the rule will be deployed on. The test for consecutive pointers is especially useful since each domain name should only ever have one pointer (at the very end), meaning we should never be seeing many pointers in a row in normal traffic.
      • This is implemented in dns_heap_overflow_variant_1.lua, which is invoked by dns_heap_overflow.rules.
  • Implementation of the detection logic above has been split up amongst several Suricata rule files since only the pointer counting logic is specific to this vulnerability. Detection of exploits leveraging this vulnerability are enhanced with the addition of the DNS layer size check, domain name compressed length check, and domain name character check implemented in the other rules, but these are considered to be “helper” signatures and flagging one of these does not necessarily indicate an exploitation attempt for this specific vulnerability.

False positive conditions (signatures detecting non-malicious traffic):
Networks expecting non-malicious traffic containing DNS names using non-alphanumeric characters or an abnormally large number of DNS compression pointers may generate false positives. Unfortunately, checking for pointers in only the domain name fields is insufficient, as a malicious packet could use a compression pointer that points to an arbitrary offset within said packet, so our rule instead checks every byte of the DNS layer. Consequently, Treck’s overly liberal classification of DNS compression pointers means that our rule will often misclassify unrelated bytes in the DNS payload as pointers.

In our testing, we ran into false positives with domain names containing spaces or things like “https://”. Per the RFCs, characters such as “:” and “/” should not be present in domain names but may show up from time to time in real, non-malicious traffic. The list of acceptable characters should be expanded as needed for the targeted network to avoid excessive false positives. That being said, keeping the list of acceptable characters as small as possible will make it more difficult to sneak in shellcode to leverage one of the Ripple20 DNS vulnerabilities.

False positives on the DNS size rules may occur when DNS over TCP is used if Suricata does not properly classify the packet as a DNS packet – something that has occurred multiple times during our testing. This would cause the second size check to occur, which assumes that all traffic over port 53 is DNS traffic and processes the payload accordingly. As a result, any non-DNS traffic on TCP port 53 may cause false positives in this specific case. It is recommended the port number in the rule be adjusted for any network where a different protocol is expected over port 53.

Fragmentation of DNS traffic over TCP may also introduce false positives. If the streams are not properly reconstructed at the time the rules execute on the DNS payload, byte offsets utilized in the attached Lua scripts could analyze incorrect data. Fragmentation in DNS response packets is not common on a standard network unless MTU values have been set particularly low. Each rule should be evaluated independently prior to use in production based on specific network requirements and conditions.

False negative conditions (signatures failing to detect vulnerability/exploitation):
False negatives are more likely as this detection logic relies on heuristics due to computation of the uncompressed DNS name length being too computationally expensive. Carefully constructed malicious packets may be able to circumvent the suggested pointer limitations and still trigger the vulnerability.


alert dns any any ‑> any any (msg:"DNS packet too large"; flow:to_client; flowbits:set,flagged; lua:dns_size.lua; sid:2020119014; rev:1;)
Lua script (dns_size.lua) can be found in Appendix A

alert tcp any 53 -> any any (msg:"DNS over TCP packet too large"; flow:to_client,no_frag; flowbits:isnotset,flagged; lua:dns_tcp_size.lua; sid:2020119015; rev:1;)
Lua script (dns_tcp_size.lua) can be found in Appendix A


alert dns any any -> any any (flow:to_client; msg:"DNS response contains invalid domain name"; lua:dns_invalid_name.lua; sid:2020119013; rev:1;)
Lua script (dns_invalid_name.lua) can be found in Appendix A


# Variant 1
alert dns any any -> any any (flow:to_client; msg:"Potential DNS heap overflow exploit (CVE-2020-11901)"; lua:dns_heap_overflow_variant_1.lua; sid:2020119011; rev:1;)
Lua script (dns_heap_overflow_variant_1.lua) can be found in Appendix A

RDATA Length Mismatch in DNS CNAME Records Causes Heap Overflow

CVE: CVE-2020-11901 (Variant 2)
Protocol(s): DNS/UDP (and likely DNS/TCP)
Port(s): 53

Vulnerability description:
In some versions of the Treck stack, a vulnerability exists in the way the stack processes DNS responses containing CNAME records. In such records, the length of the buffer allocated to store the DNS name is taken from the RDLENGTH field, while the data written is the full, decompressed domain name, terminating only at a null byte. As a result, if the size of the decompressed domain name specified in RDATA exceeds the provided RDLENGTH in a CNAME record, the excess is written past the end of the allocated buffer, resulting in a heap overflow and potential RCE.

Limitations or special considerations for detection:
Although exploitation of this vulnerability has been confirmed using malicious DNS over UDP packets, it has not been tested using DNS over TCP and it is unclear if such packets would exercise the same vulnerable code path. Until this can be confirmed, detection logic should assume both vectors are vulnerable.

Recommended detection criteria:

  • The device must be capable of processing incoming DNS responses.
  • The device must be capable of identifying CNAME records within DNS responses
  • The device should flag all DNS responses where the actual size of the RDATA field for a CNAME record exceeds the value specified in the same record’s RDLENGTH field.
      • In this case, the “actual size” corresponds to how vulnerable versions of the Treck stack compute the RDATA length, which involves adding up the size of every label until either null byte, a DNS compression pointer, or the end of the payload is encountered. The Treck stack will follow and decompress the pointer that terminates the domain name, if present, but the script does not as this computation is simply too expensive, as mentioned previously.

False positive conditions (signatures detecting non-malicious traffic):
False positives should be unlikely, but possible in scenarios where network devices send non-malicious traffic where RDLENGTH is not equal to the size of RDATA, thereby breaking RFC 1035.

False negative conditions (signatures failing to detect vulnerability/exploitation):
Since the detection logic does not perform decompression when computing the “actual size” of RDATA, it will fail to detect malicious packets that contain domain names whose length only exceeds RDLENGTH after decompression. Unfortunately, coverage for this case is non-trivial as such packets are actually RFC-compliant. According to RFC 1035, section 4.1.4:

If a domain name is contained in a part of the message subject to a length field (such as the RDATA section of an RR), and compression is used, the length of the compressed name is used in the length calculation, rather than the length of the expanded name.

Besides the computational overhead, enforcing such a check would likely result in very high false positive rates.


# Variant 2
alert dns any any -> any any (flow:to_client; msg:"Potential DNS heap overflow exploit (CVE-2020-11901)"; lua:dns_heap_overflow_variant_2.lua; sid:2020119012; rev:1;)
Lua script (dns_heap_overflow_variant_2.lua) can be found in Appendix A

Write Out-of-Bounds Using Routing Header Type 0

CVE: CVE-2020-11897
CVSS: 10
Protocol(s): IPv6
Port(s): N/A

Vulnerability description:
When processing IPv6 incoming packets, an inconsistency parsing the IPv6 routing header can be triggered where the header length is checked against the total packet and not against the fragment length. This means that if we send fragmented packets with the overall size greater than or equal to the specified routing header length, then we process the routing header under the assumption that we have enough bytes in our current fragment (where we have enough bytes in the overall reassembled packet only). Thus, using routing header type 0 (RH0) we can force read and write into out-of-bounds memory location.

There is also a secondary side effect where we can get an info leak in a source IPv6 address in an ICMP parameter returned from the device.

Limitations or special considerations for detection:
The RFC for RH0 defines the length field as equal to “two times the number of addresses in the header.”  For example, if the routing header length is six, then there are three IPv6 addresses expected in the header. Upon reconstruction of the fragmented packets, the reported number of addresses is filled with data from the fragments that follow. This creates “invalid” IPv6 addresses in the header and potentially malforms the next layer of the packet. During exploitation, it would also be likely for the next layer of the packet to be malformed. Although ICMP can be used to perform an information leak, it is possible for the next layer to be any type and therefore vary in length. Verification of the length of this layer could therefore be very expensive and non-deterministic.

Recommended detection criteria:

  • The device must be capable of processing fragmented IPv6 traffic
  • The device should inspect fragmented packets containing Routing Header type 0 (RH0). If a RH0 IPv6 packet is fragmented, then the vulnerability is likely being exploited
  • If the length of the IPv6 layer of a packet fragment containing the RH0 header is less than the length reported in the routing header, then the vulnerability is likely being exploited
  • Upon reconstruction of the fragmented packets, if the header of the layer following IPv6 is malformed, the vulnerability may be being exploited

The routing header type 0 was deprecated in IPv6 traffic in RFC 5095 as of December 2007. As a result, it may be feasible simply to detect packets using this criterion. False positives may be possible in this scenario for legacy devices or platforms. Suricata already provides a default rule for this scenario which has been added below. According to the RFC, routers are not supposed to fragment IPv6 packets and must support an MTU of 1280, which would always contain all of the RH0 header, unless an unusual amount of header extensions or an unusually large header is used. If this is followed, then a packet using the RH0 header should never be fragmented across the RH0 extension header bounds and any RH0 packet fragmented in this manner should be treated as potentially malicious. Treating any fragmented RH0 packet as potentially malicious may be sufficient. Furthermore, treating any fragmented RH0 packet with fragments size below a threshold as well as IPv6 packets with multiple extension headers or an unusually large header above a threshold may provide high accuracy detection.

False positive conditions (signatures detecting non-malicious traffic):
If all detection criteria outlined above are used, false positives should be minimal since the reported length of a packet should match its actual length and the next header should never contain malformed data.  If only routing header type 0 is checked, false positives are more likely to occur.  In the additional provided rule, false positives should be minimal since RH0 is deprecated and the ICMP header should never have invalid checksums or unknown codes.

False negative conditions (signatures failing to detect vulnerability/exploitation):
False negatives may occur if the signature is developed overly specific to the layer following IPv6, for example, ICMP.  An attacker could potentially leverage another layer and still exploit the vulnerability without the information leak; however, this would still trigger the default RH0 rule. In the second rule below, false negatives are likely to occur if:

  • An attacker uses a non-ICMP layer following the IPv6 layer
  • A valid ICMP code is used
  • The checksum is valid, and the payload is less than or equal to 5 bytes (this value can be tuned in the signature)


alert ipv6 any any -> any any (msg:"SURICATA RH Type 0"; decode-event:ipv6.rh_type_0; classtype:protocol-command-decode; sid:2200093; rev:2;)

alert ipv6 any any -> any any (msg:"IPv6 RH0 Treck CVE-2020-11897"; decode-event:ipv6.rh_type_0; decode-event:icmpv6.unknown_code; icmpv6-csum:invalid; dsize:>5; sid:2020118971; rev:1;)

IPv4/UDP Tunneling Remote Code Execution

CVE: CVE-2020-11896
CVSS: 10.0
Protocol(s): IPv4/UDP
Port(s): Any

Vulnerability description:
The Treck TCP/IP stack does not properly handle incoming IPv4-in-IPv4 packets with fragmented payload data. This could lead to remote code execution when sending multiple specially crafted tunneled UDP packets to a vulnerable host.

The vulnerability is a result of an incorrect trimming operation when the advertised total IP length (in the packet header) is strictly less than the data available. When sending tunneled IPv4 packets using multiple fragments with a small total IP length value, the TCP/IP stack would execute the trimming operation. This leads to a heap overflow situation when the packet is copied to a destination packet allocated based on the smaller length. When the tunneled IPv4 packets are UDP packets sent to a listening port, there’s a possibility to trigger this exploit if the UDP receive queue is non-empty. This can result in an exploitable heap overflow situation, leading to remote code execution in the context in which the Treck TCP/IP stack runs.

Recommended detection criteria:
In order to detect an ongoing attack, the following conditions should be met if encapsulation can be unpacked:

  • The UDP receive queue must be non-empty
  • Incoming UDP packets must be fragmented
      • Flag MF = 1 with any offset, or
      • Flag MF = 0 with non-zero offset
  • Fragmented packets must have encapsulated IPv4 packet (upon assembly)
    protocol = 0x4 (IPIP)
  • Encapsulated IPv4 packet must be split across 2 packet fragments.
  • Reassembled (inner-most) IPv4 packet has incorrect data length stored in IP header.

The fourth condition above is required to activate the code-path which is vulnerable, as it spreads the data to be copied across multiple in-memory buffers. The final detection step is the source of the buffer overflow, as such, triggering on this may be sufficient.

Depending on the limitations of the network inspection device in question, a looser condition could be used, though it may be more prone to false positives.

In order to detect an ongoing attack if encapsulation cannot be unpacked:

  • The UDP receive queue must be non-empty
  • Incoming UDP packets must be fragmented
      • Flag MF = 1 with any value in offset field, or
      • Flag MF = 0 with any non-zero value in offset field
  • Final fragment has total fragment length longer than offset field.

The final condition shown above is not something that should be seen in a normal network.

Fragmentation, when it occurs, is the result of data overflowing the MTU of a given packet type. This indicates the final fragment should be no larger than any other fragment – and in practice would likely be smaller. The inverse, where the final fragment is somehow larger than previous fragments, indicates that the fragmentation is not the result of MTU overflow, but instead something else. In this case, malicious intent.

As network monitors in common usage are likely to have the ability to unpack encapsulation, only that ruleset is provided.

Limitations or special considerations for detection:
The Treck stack supports (at least) two levels of tunneling. Each tunnel level can be IPv4-in-IPv4, IPv6-in-IPv4, or IPv4-in-IPv6. The above logic is specific to the IPv4-in-IPv4, single level of tunneling case. In cases of deeper nesting, either a recursive check or a full unwrapping of all tunneling layers will be necessary.

False positive conditions (signatures detecting non-malicious traffic):
False positives should be minimal if all detection criteria outlined above are used in the case where the tunneling can be unpacked. In the case where tunneling cannot be unpacked, this is unlikely to trigger many false positives in the presence of standards compliant applications. Fragmentation as seen here is simply not common.

False negative conditions (signatures failing to detect vulnerability/exploitation):
False negatives could occur with deeper levels of nesting, or nesting of IPv6.


alert ip any any -> any any (msg:"IPv4 TUNNELING EXPLOIT (CVE‑2020‑11896)"; ip_proto:4; lua:tunnel_length_check.lua; sid:2020118961; rev:1;)
Lua script (tunnel_length_check.Lua) can be found in Appendix A

Appendix A

Appendix A contains Lua scripts that are required for usage with corresponding Suricata signatures. These scripts are also located on McAfee ATR’s GitHub.







The post Ripple20 Critical Vulnerabilities – Detection Logic and Signatures appeared first on McAfee Blogs.