Opinion: Spam over Internet Telephony has the potential to be the most annoying variation ever. It has to be stopped emphatically and fast.
Its largely theory so far, but not entirely. There have already been reports of voice spam using voice over IP systems in Japan. Its hard to imagine a more disruptive and aggravating form of spam than Spam over Internet Telephony, known with tongue in cheek as SPIT.
Even on landlines the marginal cost of a telephone call is being driven down towards zero over time, but on VOIP its already there in many cases. In many VOIP networks, such as Skype, calling from one user to another is free. The economics are too inviting for spammers to ignore.
Its not hard to imagine different sorts of attacks that could be perpetrated, especially in combination with a voice response system.
To begin, the spammers could harvest phone numbers the same way they harvest e-mail addresses, but they dont have to. They can just buy online phone books complete with names and addresses.
With this data, the spam could seem even more legit since voice synthesis could say "Hello Mr. or Mrs. Seltzer." Further credibility comes from the fact that falsifying caller ID is easy to do and not necessarily illegal.
The spammer doesnt know what the marks bank is or if they are a Paypal customer or anything like that (well, with enough data mining perhaps they could, but lets not go that far). But the spammer would know the municipality, and they could determine the school system and utilities.
These and certainly many others present the opportunity for lots of effective scams. And with a phone directory for a company you could design special attacks aimed at those persons.
The impact of SPIT doesnt stop with the fraud. A concerted SPIT attack could be used to create a denial of service for a companys or service providers VOIP network or at least their voice mail system.
Its also not hard to imagine PC-based VOIP clients, not necessarily Skype but any service with a soft phone, being hijacked by malware into becoming a VOIP spam bot.
Click here to read about how the buzz around VOIP is quieting down.
If the soft phone is programmable by other software on the system and the bot can install a virtual microphone driver then calls could be placed in the background and the user wouldnt necessarily know.
They could tell if they scrutinized their own usage or if the bot interfered with their own use of the VOIP system. A smart bot could stay out of the way of that.
The answer to the spam bot is mostly the same answer for regular bots: user should secure their systems against malicious software and application vendors should secure their programs against abuse.
Of course, its like telling kids to eat their vegetables; it doesnt always get done and its not always worth the abuse youll get to force the issue. So some level of this sort of bot activity seems inevitable.
Conventional anti-spam approaches to SPIT wont necessarily work. Bayesian analysis that might work well on text streams is not, at least as a practical matter, going to be up to the task of analyzing voice streams in packets.
And while it remains to be seen just how much they can get away with, it appears that much of the data exchanged in the signaling phase of the call can be forged.
The solution to SPIT from dedicated spitting systems is harder than stopping spam. It depends on the good will of VOIP providers and perhaps even law enforcement to take the problem seriously and crack down on violators.
Compared to that, getting kids to eat their spinach is easy.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
Check out eWEEK.coms for the latest security news, reviews and analysis. And for insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzers Weblog.More from Larry Seltzer
Larry Seltzer has been writing software for and English about computers ever since,much to his own amazement,he graduated from the University of Pennsylvania in 1983.
He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.
For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.
In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.
Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.