Quantcast
Channel: McAfee Labs, Author at McAfee Blog
Viewing all 203 articles
Browse latest View live

Did You Forget to Patch Your IP Camera?

$
0
0

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.


Floki Bot a Sensation With International Cybercriminals

$
0
0

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.

Next Targets for Cybercriminals: the Short Term (Part 1)

$
0
0

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.

Next Targets for Cybercriminals: the Long Term (Part 2)

$
0
0

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.

Top Tips for Securing Home Cameras

$
0
0

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.

Further Analysis of WannaCry Ransomware

$
0
0

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:\Intel\<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:\Intel\<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.

Everyday Hero: 5 Questions with McAfee Labs’ Paula Greve

$
0
0

With 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 intel 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.

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

McAfee Labs: Faceliker Surge Manipulates Facebook “Likes” to Promote News, Other Content

$
0
0

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.


‘McAfee Labs 2018 Threats Predictions Report’ Previews Five Cybersecurity Trends

$
0
0

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.

Phishing Threat Uses UTF-8 BOM in ZIP Signature to Evade Detection

$
0
0

This blog was written by Sanchit Karve.

Last week, we noticed thousands of malware files in the wild that employ a simple phishing attack by modifying the hosts file on Windows systems. What’s interesting, however, is the technique chosen by the malware authors to distribute their payload. The samples in question (Example MD5: 34d9b42bfd64c6f752fe27eef8d80c5f) are packaged in a ZIP file along with a 0-byte readme.txt file.

Usually, ZIP files start with the ZIP signature 0x04034B50 (or “PK”, 03, 04), but in this case the author chose to insert the UTF-8 Byte Order Mark (BOM) (represented as 0xEFBBBF) before the ZIP header.

sanchitkarve_ziputf8

Unicode BOMs are often used to indicate the endianness of encoded textual data. It is redundant for UTF-8 data, as byte order has no meaning in UTF-8, which is why the Unicode Standard leaves it as optional and does not recommend its use. Despite this, it is not uncommon to see UTF-8 BOMS in text files and data streams. For example, many popular applications (Notepad, Google Docs, etc.) use the UTF-8 BOM to explicitly state that a document is encoded with UTF-8.

Because the ZIP file is prefixed with the UTF-8 BOM, it tricks many applications into assuming that the file is a UTF-8-encoded text file. For example, when such a file is opened by Windows 7, the OS complains that such a ZIP file is invalid. Some third-party archive programs, such as 7-Zip, WinRAR, and some others ignore the BOM and read the ZIP file correctly.

Because the only way to run the file is to manually extract and execute it, the malware authors expect their victims to have third-party archiver applications installed on their computers.

It is also likely that the authors using this technique want to evade detection from antivirus products and email spam filters that adhere strictly to the ZIP format. Even though most of the samples are virtually the same, they generate unique hashes due to the varying timestamp fields embedded in the ZIP header as well as differences in the installers’ overlay sections caused by varying application names.

As for the sample itself, the main payload is an installer that always bears one or more of the following words: Golaya, Russkaya, or Devochka (which together roughly translates to “Naked Russian Girls” in Russian).

This installer silently executes batch and VBScript files to modify the hosts file on a victim’s machine and map IP addresses to popular Russian websites as shown below:

sanchitkarve_hostsFile

When users visit one of these websites, instead of being connected to the site’s IP, they are instead connected to the IP address listed against the site name in the hosts file. Like any other phishing attack, the page hosted at the IP address in the hosts file looks almost like the original site, and is the perfect bait to lure users into unknowingly giving away their account credentials.

This threat has been growing steadily over the past few days. VirusTotal reports that it currently has more than 5 million submissions of this malware family.

McAfee detects this threat as Trojan-SkyHook, Agent-FBH and Agent-FBX.
Thanks to my colleague Srinivasa Kanamatha for discovering the anomaly.

The post Phishing Threat Uses UTF-8 BOM in ZIP Signature to Evade Detection appeared first on McAfee Blogs.

Necurs, Zbot Droppers Use Obfuscated Windows XP Detection to Bypass Automated Analysis

$
0
0

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.

Dofoil Downloader Update Adds XOR-, RC4-Based Encryption

$
0
0

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.

Taking a Close Look at Data-Stealing NionSpy File Infector

$
0
0

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.

Verizon Report Foreshadows Breaches Originating With IoT Devices

$
0
0

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.

McAfee Labs Threats Report Highlights Surge in Ransomware, Flash Exploits, Firmware Attacks

$
0
0

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.


Secure Your Instance of Amazon’s Elastic Compute Cloud

$
0
0

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.

Server-Side Request Forgery Takes Advantage of Vulnerable App Servers

$
0
0

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.

5 Steps to Enhance Security of Cloud Applications

$
0
0

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.

How to: Testing Android Application Security, Part 1

$
0
0

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.

How to: Testing Android Application Security, Part 2

$
0
0

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.

Viewing all 203 articles
Browse latest View live