Complexity and Scams
Tech @ FTC 2013-03-15
All of us use gadgets—cars, phones, computers, what have you—that we don’t really understand. We can use them, and use them very effectively, but only because a great deal of effort has been put into making them seem simple. That’s all well and good—until suddenly you have to deal with the complexity. Sometimes, that happens because something has broken and needs to be fixed; other times, though, scammers try to exploit the complexity. The complaints released today by the FTC illustrate this nicely (the press release is here; it contains links to the actual filings), with lessons for both consumers and software developers. (It turns out that programmers speak a different language than normal people do—who knew?)
It’s a long story, but I can summarize it easily enough: scammers call people claiming to be from a reputable vendor. They trick their victims into thinking that their computers are infected, and persuade them to fork over $100 or more.
The scam starts innocently enough: people receive a call telling them that their computer “may” be infected. (The call itself may be illegal if it’s a “robocall”—do you know about the forthcoming FTC Robocall Summit? Even if it’s not a robocall, it’s illegal if the recipient is on the Do Not Call list.) The caller will claim to be from a computer or computer security company. (I received such a call, well before I joined the FTC; that person claimed to be from Microsoft. Yes, I’m on the Do Not Call list.) The victim will be talked through some steps designed to “demonstrate” that their computer is infected. You’re then given the “opportunity” to pay them for fixing it.
Lesson 1: Be extremely skeptical if someone calls you; reputable security companies don’t “cold call” people. If you have any doubt whatsoever about the legitimacy of the caller, call back using a number you’ve learned independently, perhaps using a phone number from their web site. (This issue is broader than just this scam. For example, if a caller claims to be from your credit card company, don’t give out any information; instead call back using the number on the back of your card. And don’t believe Caller ID; it’s easily spoofed. There are also lessons here for developers, but I’ll save those for another post.)
This is the most important lesson to learn: “Don’t call me; I’ll call you.”
It’s worth noting that scammers in this case did in fact use Caller ID spoofing, to make the calls appear to be coming from the U.S. rather than India. That turns out to be remarkably easy to do. Here’s the crucial question: when a call starts on one phone company’s network but terminates on another’s, how does the receiving company know the caller’s number? Answer: the receiving company believes whatever it’s told, whether the information is coming from another phone company or a private branch exchange (PBX). This worked tolerably well when there were only a few, large telcos; now, though, there are very many—and every Voice over IP (VoIP) gateway to the phone network counts as a telco or PBX.
That trust model no longer works. There are many more telephone companies than there once were, and there are very many VoIP gateways. If even one doesn’t check the Caller ID asserted by its customers—and there are valid technical reasons not to, in some situations; consider the case of an employee who wants to make an expensive international call via the company PBX—it’s very easy for a malefactor to claim any number he or she wishes. (Note that using fake Caller ID “for the purposes of defrauding or otherwise causing harm” is illegal.) One of the accused firms here claimed to be calling from Quinnipiac University or New York City; another claimed to be from Texas, etc.
In this particular scam, the victim is asked to run a program called the “Event Viewer”. Most computer systems log various things that take place, including mildly anomalous conditions; Event Viewer is the way to display such logs on Windows. The information is often quite cryptic, but invaluable to support personnel. Cryptic? Yes, cryptic, as you can see below.
The point is that you’re not expected to understand it; it’s information for a technician if you need help.
The consumer is then directed to look for “Warnings”. That sounds scary, right; your computer is warning you about something. Lesson 2: Programmers use words differently. On most computer systems, warnings are less serious than errors; you generally don’t need to do anything about a warning. Contrast “Warning, your disk is 90% full” with “Error: no space left on disk.” That isn’t normal usage (to the Weather Service, a storm warning is more serious than a storm watch, which is why programmers get confused when they listen to weather reports…), which gave the scammers one more thing to exploit.
Next, of course, it’s time to scare the consumer—“Jesus, did you say warning?”—followed by completely bogus cautions to avoid clicking on the warnings. (What happens if you do click on one of those messages? Nothing bad; you just get a new window with more information, and a URL to click on to get even more details. That’s what the screen shot shows.)
It’s also worth realizing that even most of the errors logged are quite irrelevant and harmless. That isn’t always the case, but more or less any machine will experience many transient or otherwise meaningless failures, perhaps induced by things like momentary connectivity outages.
There’s also a lot of technical doubletalk, presumably intended to impress the victim with the caller’s expertise. Most of this is pure nonsense, such as (in one call from an FTC investigator) learning that “DNS” is “dynamic network set-up”. The DNS, of course, is really the “Domain Name System”, the Internet mechanism that translates things like www.ftc.gov into a set of numbers that the underlying hardware really understands. My favorite was hearing that “the Javascript in your computer has been fully corrupted”. Javascript is indeed a programming language, but its primary use is creating dynamic web pages. It’s not normally “on” your computer in any permanent sense; rather, Javascript programs are downloaded to your web browser when you visit most commercial web sites. (These programs are run in what is called a “sandbox”, which in theory means that they can’t affect anything on your computer.)
Lesson 3: Just because someone can spout technical terms it doesn’t mean they’re knowledgeable or legitimate. Of course, asking them to explain what they’re saying doesn’t prove much; they can respond with more glib doubletalk. A legitimate support tech can probably explain things somewhat more simply; however, while lack of technical details might be a good reason for suspicion, the presence of them says very little.
The victim is then told to download and run a program from the scammer’s web site. That’s bad, too—you should never run a program from an unknown source—but of course by this time the victim does trust the caller. But this is really dangerous: once you run someone else’s code, it could be game over for your computer; it’s really, really hard to disinfect a machine thoroughly. The same applies to credit card numbers: once you give it out, you could be charged far more and far more often than a one-time payment to a scammer.
Where does this leave us? Like most con artists, the callers here are trying to gain your trust before ripping you off. The best thing is to cut them off at the start. Remember Lesson 1—“Don’t call me; I’ll call you.” —and use a number that you’ve looked up on your own.