SecureMac Roundup: Even More Listener Questions Answered
Last week, we answered listener questions. This week — we’re answering more listener questions! Podcasts are mostly about conversations, but it’s not just about conversations between our hosts. It’s also about discussions between our listeners and us. Remember: if you have a question, chances are, someone else has that same issue too! Check out the show notes to learn more about how you can send in your questions.
Today’s topics will include:
- Scam pop-ups
- App-specific password requirements
- Issues with SS7
- Some oddity around an email address
Problematic pop-ups won’t seem to disappear
Listener Steven starts us off today:
“I’m being plagued with a problem, and it does not matter how many times I run MacScan, it still happens. I lose my web page and get a page with audio stating all my bank and credit card info is being stolen. This overrides everything. I cannot get rid of it. I was also told I passed on a virus to a friend. Can you explain?”
We’ve covered a little about a similar topic in a previous episode of The Checklist. It sounds like a well-known scam that has been floating around the Web for a few years now. The chances are good that what is happening here is an instance of malvertising. There is probably a malicious ad on a web page you’re visiting that triggers these problems.
This ad might have been placed intentionally by the bad guys; in many cases, they’ve hacked the site without the owner realizing the problem. They may have also compromised an advertising server used by the host site. As you visit an infected site, you might get a pop-up ad — and if your volume is on, it could start speaking with your Mac’s voice. Most often, it presents some warning about how your Mac has tons of viruses, or in Steven’s case, that identity theft is underway. Usually, it also features an ad or pop-up box encouraging you to download something.
There is a fix: if you force-quit safari, then hold down the shift key and re-open the program, it will force Safari to run in safe mode. It won’t load any pages you had open previously as it usually would, and it should stop the pop-up from showing up. Now, keep in mind it will return if you go back to the website that had the bad ad on it — so beware. However, there are a few ways to help mitigate this threat.
Try installing an ad blocker or a specific Safari content blocker to avoid the problem. If the ad doesn’t load, the code causing the pop-up won’t load either. If it’s not malvertising, though — if the site itself has been hacked — and it is a site you normally visit and generally trust, contact the site administrator! Let them know you’re a visitor on a Mac and that you’re experiencing a major problem on their page.
With a report like yours, they can investigate to determine if something is wrong with one of their ad providers or if someone hacked into their server. Most ad providers are very good at cracking down on these bad ads once they know about them. Unfortunately, the bad guys will keep coming back under different names, hence this problem persists.
Trying to access copyrighted content and other pirated material is one the most common avenues where these problems occur. If you want to watch the latest blockbuster movie at home, you might type the name of the movie and the word “streaming” into Google — it’s worked for you before, right? Well, most of the sites you’ll find in the results are not only highly unlikely to have the movie in question, but also more likely to contain these spam pop-ups, malware, and malvertising. Never download or run anything offered to you by a pop-up, especially on one of these fake streaming sites! If you do, you should run your security software right away as you’ve likely infected your Mac with adware.
What about scanning to stop the problem? With the way MacScan’s SmartScan feature works, it knows to look in all the places malware most commonly hides. That includes the places where it must reside to run every time your Mac starts. If you run full scans (as opposed to scanning for cookies), you should be rooting out any of the bad stuff on your machine.
How can you tell the difference between a bad ad and an adware infection? Consider this: if you see pop-up ads on a site you know would never have them, like Google.com or Apple.com, it’s a good bet you have adware. If it’s only when you visit one specific site, it’s probably a bad ad. A full system scan should be done to clear out the problem. If the scan doesn’t turn anything up, contact your software provider! Sometimes, there is adware that is just too new to have been detected yet. Once security companies know about them, they can create new definitions to enable removal.
What’s up with app-specific passwords?
Our next question comes to us from Bill:
“As of this past summer,” he says, “Apple is enforcing app-specific passwords for third-party apps that access iCloud data. These appear to apply principally to third party calendar and email apps. To do this, one must also turn on two-factor authentication on one’s Apple ID. Could you cover the rationale and the process needed to accomplish this? Are these app-specific passwords and two-factor authentication requirements being enforced globally, or just in the USA?”
To improve user safety, Apple wanted to restrict access to iCloud accounts, so other apps do not have access to your actual iCloud login information. These apps don’t need that sensitive information, after all, and some weren’t treating it with respect. Some apps were sending data insecurely to their servers and then logging you into iCloud, for example, and that’s just not safe. As a result, Apple made some changes.
They required these third-party apps to either integrate directly into iCloud by using Apple’s secure API or to use a new password separate from your iCloud password. This way, the most sensitive credentials wouldn’t need to be entered directly into the app. In other words, if an app developer went through the proper steps to implement Apple’s API and integrate into iCloud, there is no need for an app-specific password. That is only for those apps that don’t have it set up for whatever reasons. It makes it simpler to protect your iCloud ID and to control access through third-party apps.
It is true that you must enable two-factor authentication for this to work. With iOS 10.3 and newer versions, this was already enabled by default by Apple, so you don’t need to worry about doing anything. Users upgrading will be prompted to enable it, so it should already be set up for you. Apple has a page with directions on how to set up and generate app-specific passwords, which you can find here. You’ll need to do this separately for every app that doesn’t use the Apple iCloud API — you’ll know which they are because they will prompt you to create such a password.
If you do have to change your Apple ID password at some point in the future, it will automatically revoke all these app-specific passwords as a security measure. At that time, you will need to re-generate them. Apple allows for up to 25 app-specific passwords at any given time, and you can also revoke them on a case by case basis as needed. This change does seem to be global and for all users across the board, and it makes sense — it’s just good security.
Addressing the SS7 vulnerability
Harvey is up next! He writes in:
“In your otherwise thorough show on authentication and authorization, you failed to discuss the SS7 cellular network flaw that enables someone with your cell phone number to receive your texts. It’s a serious objection to using SMS as a second factor. In a follow-up episode, I hope you will discuss the implications of the SS7 flaw and specifically what factor to use instead. You discussed hardware tokens, but not the SS7 context; is, for example, the Yubico key a better alternative?”
Let’s take that apart a bit by going in-depth on what Harvey means by the “SS7 flaw.” SS7 stands for “Signaling System 7,” and it’s a set of protocols used in telephone networks, dating back back in the 70’s, so it’s been around for a while now. Among other things, SS7 allows your phone call or text message to travel from one carrier to another. So, if you have AT&T for example, you’d naturally want to be able to call or text people who are on Verizon, or Cricket, or Sprint, or even international carriers like Vodafone. SS7 makes this happen; it’s also what allows your phone to operate in roaming mode when you travel away from your provider’s network.
There are some flaws, of course, because this is a system designed years ago and built not so much with security in mind as we’d hope today. Some news stories have cropped up recently where flaws in SS7 have allowed bad guys to do some bad things. In May of 2017, a German mobile service provider confirmed that criminals had used SS7 vulnerabilities to bypass 2FA to steal money from bank accounts.
Now, this isn’t necessarily an easy thing to accomplish — you won’t have some random teenager at home looking up your phone number online and stealing all your money. In the case in Germany, the criminals first had to install malware on people’s computers. They also had to obtain the login and password information for the bank account in question, plus the account holder’s phone number. That’s already plenty of information for a bad guy to use to break into your account if you bank with a company that doesn’t require or use 2FA. With 2FA, of course, they send a one-time passcode to your phone as a text.
To get around that, the bad guys then had to set up a fake telecom provider, then set up a redirect for the victim’s phone number, so it went to the system they operated instead. Only from there could they intercept the one-time passcode generated when they tried to use the account credentials to log in. It’s not easy by any stretch of the imagination — it required serious time and technical skills to pull off.
As ingenious and even unsettling as this undertaking was, it’s not a reason to turn around and say that SMS is now worthless for use in 2FA. It’s not. Yes, the flaws in SS7 are concerning, but for the average user, the risk is remote. For now, there are a limited number of ways to accomplish 2FA, and SMS is the easiest and most available method for most people. For many users, it’s still an excellent method to use.
Now, there are alternatives, as Harvey mentioned with the Yubico keys. These are little USB sticks that plug into your Mac or other device and generate one-time keys for secure logins, without any need to communicate over cellular networks. They’re similar to the older RSA SecurID keys we’ve discussed previously. The problem here is that not everyone supports these keys, though many do; Google supports Yubico, for example, as do Facebook, many of the password apps, and others. As of macOS 10.12 and later, Apple also supports it, but you probably won’t see much widespread adoption at this point. For now, it won’t be able to entirely replace SMS as a 2FA option unless your application provider chooses to offer support.
Is this an email impostor?
John joins us to close out the day: “A few days ago I received an email from a friend, and I was about to reply when I noticed that, although the username was correct, the domain was different. For example, instead of “firstname.lastname@example.org,” the email I received was from “email@example.com.” I wrote her about this, and she replied in a couple of days that at least one other person had emailed her with the same info. I was curious as to what exactly is going on here.”
Now, “yft.il” is obviously a bogus domain — it doesn’t exist — but let’s assume that John was merely offering an example and that the actual confusing domain looked much more similar to Yahoo. So, what is going on here? There are a few things that could be happening.
A user who has fallen prey to a phishing attack is the most common scenario here. They might have clicked a link to get to their webmail provider and thought they were logging in to the real provider, but in fact, it was a fake page set up to capture their email credentials. At that point, the bad guys can download their address book and start spamming people with the victim’s name. It might be pure spam, or it might be a new phishing attack. Sometimes it could be related to a breach in a website or 3rd party service where perhaps you have a list of contacts. What better way to spam somebody than to make it look like it’s coming from a friend or relative?
Let’s also consider for a moment that perhaps this is not a phishing attempt. If the domain in question doesn’t exist, it could be something as simple as a misconfigured email client. Maybe they accidentally ended up in the settings for their outbound email address and made a typo. Suddenly, their emails won’t look like they’re coming from quite the right place. Have you ever had a problem where it appears no one was receiving your messages, but you could get emails just fine? Check your outbound settings to make sure everything is set up correctly. It won’t be an issue for webmail clients, but if you use Outlook or something like Apple’s built-in email client, checking your settings can help to resolve many problems.
Look at the content of the email you received, too. Does it look legitimate — like something your friend would typically write? Ask them about the email contents and see if they remember sending it at all. This info can help you to determine whether you’re staring down a phishing attempt, or just looking at a simple settings problem.
But to be fair, more often than not these are phishing attempts. Emails that look like they’re from someone you know, but it’s a short email that says “Thought you’d enjoy this” followed by a strange URL – Those are almost always phishing scams and you should definitely not click those! It never hurts to contact your friend and let them know you received something that looks like it’s from them. It might be a good time for them to consider changing their passwords.
That’s all we have for this week’s edition of The Checklist brought to you by SecureMac. Remember, we’re always happy to get your questions and share our insight with you. We’d love to hear from you. Join the conversation and email us at firstname.lastname@example.org. We’ll see you again next week!