Checklist 61: App Stores, Malware, and How Security Firms Do Their Jobs

For years, people laboured under the misconceptions that Apple hardware and operating systems were immune to the threats and malware faced by the people who use Windows. While macOS may be stronger in some respects, what made the Mac the safest was the fact that relatively few people used it compared to Windows. But times have changed! For most of the past decade, growth for Apple machines has outpaced that of Windows machines. General consumers “saw the light” through the iPod and the iPhone and decided to give the Mac a try. Students choose to take Macs to school in increasing numbers, and businesses are letting employees use Macs instead of Windows for their work tasks.

More and more people are using Apple hardware and software, and that can only mean one thing: attracting the attention of miscreants, hackers, and other bad actors. While Apple has the attention of the bad guys, it’s also got the attention of the good guys, too. These are people who’ve made jobs for themselves keeping your computing environment safe — or as safe as it can be. That includes the team here at SecureMac. Sometimes, we professionals uncover vulnerabilities on our own — but what happens then? Today we go behind the curtain to give you a look at what SecureMac and other firms like ours do when we spot something bad happening.

Finding the flaws: where does it all begin?

We’ll start by looking at the answer to a common question: how do we discover these things? How does a vulnerability catch our eye? Like many things, the answer all depends on the context and the circumstances. Some security researchers go looking for vulnerabilities, for example, using tools built for the job or through their own careful analysis of programs and apps. They’ll do this to explore for any potential avenues that could be used to find or exploit a vulnerability in the program. That’s just one route, though.

There’s another very common route for uncovering potential issues: customers. Customers typically report problems through an email directly to a security company, forum posts on the Web, Twitter posts, or even a tip from friends and family. As someone in the information security realm, we might realize the problem described to us could be an issue. An initial tip-off leads to more research as we tug on that first thread, hoping to unravel something bigger as we dig deeper. Which route a researcher takes is down to their personal preference, usually. There are some who are much more proactive, seeking out flaws each day, and there are others who work other projects but happen to be in the right place at the right time with the right knowledge for identifying a problem.

Reports from regular users are incredibly important for fighting back against the bad guys — those are often the first indication that something new is out there. However, how do we differentiate between something that could be a real flaw and problems that might be due to some other error? It’s important first to understand that as researchers, we get emails all the time — and we don’t automatically think you’re paranoid for wanting more information on an issue concerning you.

Many times, after researching a reported problem, we conclude that the reported issue is a problem unrelated to malware or a vulnerability. It might be a hardware problem, such as bad RAM (which can cause all sorts of crazy problems), or something as simple as a wireless mouse that needs new batteries. Even so, we need to take steps to make sure it isn’t a problem first. At other times, red flags go off as soon as we read the email. When a user complains of a problem “ever since I downloaded this program” or something such as, “When I use Safari, this strange thing keeps happening,” it clues us in that something like malware could be at play.

When a customer reports like: “I’m using your security software, and it’s not catching anything, but I still think I have a problem,” that’s especially concerning. That might happen with new variants of existing malware or a brand-new threat. Be a part of this process — when strange things happen, and you worry, take notes of about what happened, write down what you saw, and what links (if any) you clicked or which screens appeared. You can help by notifying your provider with this data.

The differences between glitches and vulnerabilities

In the past, the reports we handle broke down to nearly a 50/50 split between real threats and people simply making mistakes or working with faulty hardware. Over the last few years, though, that ratio has tilted more heavily towards real threats. Especially on Mac, we’ve seen a huge rise in adware, and these malicious developers work day in and day out to pump out new variants and design changes to avoid detection.

If we come across something in software, how do we make the distinction between what’s a harmless glitch and what could be a real threat? It boils down to what’s actually happening, so it helps to pay close attention to what’s happening on screen. If you’re resizing a Mac app’s window, for example, and one of the buttons doesn’t track into the correct position, that’s probably just a developer’s mistake. In newer versions of macOS, issues like that could even be bugs in the system. Apple is still working out the kinks in these new versions, and we’ve been facing an issue that offers up a good example.

In the latest version of High Sierra, users who click the “close” button on third-party app notifications won’t be able to close the box. Instead, High Sierra performs the action linked to the notification box. In MacScan, that works out to mean that when a user tries to close a notification about clearing cookies, they receive the scan log instead. This behavior isn’t a bug in the program, but rather a glitch in High Sierra that affects a whole host of developers. This kind of behavior is especially concerning because although it isn’t a security issue, it’s easy enough for it to look like one at first, especially to the general user. Hopefully, Apple issues a patch for this soon!

If you encounter a program that doesn’t handle user input well, like when entering text into a text field and clicking buttons, it’s more concerning. Glitches related to input or external data could be more of an indication that your software might not handle the data it receives correctly. That would make it a prime candidate for a vulnerability. In short: if it’s something like a graphics glitch, it’s usually not a big of a deal. If you’re entering text and you get strange error messages or the app even crashes, it could be more troublesome.

A good first step if you encounter something like this and want to figure out for yourself if it’s something worth concern, do a Google search for the app name and some keywords related to what happened. You should be able to find other people discussing the glitch on forums or other websites, which can give you valuable information about what’s going on. Check out the app’s reviews, too — lower scores probably mean the app simply could have been poorly developed. If you a see a lot of positive reviews, though — so many that it seems unusual — and you’re experiencing all kinds of weird things with the app, it’s probably too good to be true. When the bugs or strange behavior is easily repeatable, take the time to contact the vendor and let them know.

Your checklist for reporting security concerns

Still not sure when it’s worth raising the alarm and when it isn’t? Before you send something off to your vendor, try using this checklist first.

• Step one: Reboot your machine. Yes, this really should be your first step almost every time — it can solve tons of problems that you can’t see behind the scenes. From processes running away with memory leaks to overly large temporary files, all kinds of things can happen. That’s especially true if you run your machine for extended periods between reboots. Try this first, then see if the issue persists.
• Step two: Make sure you’re running the latest version of the software. Check for updates and install the latest version, if possible. This act alone can solve several issues. Check to ensure your operating system is up to date as well.
• Step three: Try to replicate the bug. If you can make the problem happen almost 100% of the time every time you take a certain sequence of actions, the developer will definitely want to know.
• Step four: If you can replicate the bug, document the process for replication as it can make locating and fixing the bug much easier. Take screenshots along the way and write down the exact steps you took. If you cannot replicate the bug, or can’t do so with consistency, try to write a thorough explanation of what happened.
• Step five: If the app produced a crash log that appeared on screen, copy and paste this information into a text file to send along to the vendor. While clicking the “send” button on the report will submit it to the developer if it is an official Mac App Store app, any other software will send the report to Apple instead. Save time for all parties by including the crash log in your email.
• Step six: Contact the vendor through their official support system. This method of contact could be a support ticket system, or there might be a specific support email address listed online. Don’t email the webmaster or sales or another department — you want to put your concerns in front of the developer first. At this point, you can sit back and let them work on the problem. If they have any questions for you or solutions to offer, they’ll be in touch with you to help you work out the issue.

What happens after you report a problem?

Let’s turn our attention to the next phase of the process — everything that occurs after you identify a troubling problem and submit it to your vendor. When we receive an issue, what do we do? The answer boils down to the specific case. For example, if a user contacts us with information about a bug in macOS, we’ll suggest the user contact Apple directly. If it’s a piece of malware, however, reporting it to security vendors is preferable.

The first thing we’d do as a security company after receiving a new malware report would be to determine where that malware is coming from so we can locate a sample. It’s helpful when you can report details, like what download link you clicked to get the dodgy software, or which websites you visited. You may even still have the installer itself, which is an incredibly valuable sample, especially if you haven’t run it yet. Once we know the distribution vector, and we have a sample in hand, we can get to work cracking into it to analyze the malware.

To do this, we’ll run the malware on a virtual machine, usually on a dedicated test computer that isn’t connected to a network. This way, we don’t infect ourselves, and we have a safe environment for analysis. This method is an effective way to start assessing the sample’s capabilities and what type of network traffic it generates. We use a variety of tools at this stage.

Static analysis tools allow us to dig into the low-level code of the sample. With this, we can parse the code function by function to try and unpack what it does at each step of its operation. There are also dynamic analysis tools that allow the program to run under our control, so we can trigger certain behaviors and observe the results in real time. All this is about trying to figure out what it does locally, like logging keystrokes or stealing files, alongside determining whether it’s communicating with a command and control server or taking other actions.

Once we have an idea of what it does, we can begin to generate malware definitions to allow our software to detect the malware. You can think of a definition kind of like a vaccine — it contains enough information on the core components of the malware to allow for detection and protection, but not enough to make it infectious itself. The methodology for this varies from company to company. Some use machine learning, for example, to teach software how to recognize the sample. Others use static definitions, while others use real-time scanning to cross-reference running software with known malware code.

Now this is rarely the end of the road. Malware authors are pros, and they’ll notice when antivirus programs start to scoop up their malware. It can then turn into a game of cat and mouse as the malware developers pump out updates and new variants to try to avoid detection, while researchers try to monitor for these new releases to create updated definitions as fast as possible.

Based on what the bad guys change, some definitions can continue to catch new variants based on the broader malware signature. When they alter the code to avoid detection, though, like encrypting the malware contents, that often demands a brand-new definition. As a result, that’s why you often see frequent definition updates. In fact, sometimes we discover that what we think is an initial variant is actually newer — there were simply older versions that no one detected.

Sometimes, the bad guys will even use the tools we use as researchers to help them learn how to detection. VirusTotal, a site for uploading malware samples to check against known definitions, is often used by malware developers to check and see if their programs will be caught. We can sometimes go back after the fact and look at a history of submitted samples to see how the developer’s work evolved over time.

Getting the word out about new or serious threats

There is a lot more that goes into fighting back against malware after discovering a new sample. Creating definitions and distributing them to the users of security software is a crucial step, but it isn’t the only one — it’s important to go beyond just protecting the users of one piece of software. There are many lists and groups within the community for sharing information and for reaching out to trade samples and compare notes. Everybody works together to gain more information to better protect our users.

After we handle a new sample and create definitions, we continue working behind the scenes to produce a technical write-up on what the malware does, how it’s distributed, and how to protect against it. We and other researchers can then share this information with the security community. Getting the word out about hacked websites or malware distribution sites can also take the form of emails to our users or posts on social media.

There’s still more work to do, though. We can play cat and mouse with malware developers all we want, but if the distribution sites are still out there, there will continue to be new infections. At this stage, there are a few different things a security team might do depending on where the malware is hosted. If it’s hosted on the Mac App Store, for example, we’d contact Apple and let them know about the problem. If it’s a third-party app that’s not in the Mac App Store but the code is properly signed, it means the bad guy is in Apple’s developer program. We’d report the information on the signature to Apple so they can revoke that particular certificate so that Macs won’t run the bad software.

If it’s not a code-signed app, though, options become more limited. For something on a file distribution site like MacUpdate, we’d usually contact them directly and let them know which page was serving up malware. For a site hosted in another country, though, it’s a lot more difficult to get that site taken down. We might try to notify the hosting provider, as distributing malware is obviously against the Terms of Service. As we go farther away from the App Store and valid Developer IDs, though, stopping the flow is more difficult.

Knowing when to share information and try to raise awareness is important. Some scenarios are more serious than others. As a security team, SecureMac has been responsible for several malware takedowns, and we work hard to do due diligence in notifying sites when they’re serving up bad software. We’ve been involved in some bigger cases, too. A while back, there was a Trojan horse virus called DNSChanger affecting Macs and Windows, redirecting people to rogue DNS servers. In other words, when users tried to visit a website, their computer would query name servers controlled by the bad guys, allowing for the injection of ads, user tracking, and all kinds of harmful stuff.

At the time, we released a free removal tool to help users rid their machines of the virus. We were involved in a consortium of security firms working to fight back against DNSChanger due to how widespread it was; even the FBI got involved, taking over the servers after arresting the operators. This instance was one of the first major times we encountered malware where spreading the word far and wide about protection was most important. Remember, this was still the period of the “Mac vs PC” ads, and the idea that “Macs can’t get malware” was still very strong. We’ve also shared information about other types of malware and released additional free removal tools to aid users.

It’s all about gauging the threat level and understanding the risks. The goal is always to protect as many users as possible, and when threats are very severe, it’s important that everyone, customer or not, knows about it. From the first report from a user about some strange behavior to the deployment of widespread fixes, it’s easy to see there’s a ton of effort that goes into keeping our computers safe.

That’s all we have for this week on The Checklist. Questions, comments, or have a topic you’d like to hear us cover? Send an email to checklist@securemac.com and let us know what’s on your mind! We’ll be back again next week.