it's that time of the year again: in recent days and weeks I'm receiving annoying numbers of annoying "support" calls from dubious "MicroSoft Centers" telling me that my computer generates errors and / or downloads malicious SW. Although ignoring these pesterers on the phone, I'm a bit concerned as I can't assess the danger they pose, coming in via VoIP.
Very few ports are open on my PC interface: SunRPC and 766 (both listened on by rpcbind), CUPS, DNS and Link-Local Multicast Name Resolution (both listened on by systemd-resolve). On my router, none of the common ports is open to the WAN.
No indication (yet) of remote interaction (attempts) in my system log file.
Does anyone of you have an idea or indication, what the threat would be and how I could prevent any damage? Can they, from VoIP connection / communication data, infer / deduct / extract information allowing them to harm?
Hi R�diger,
As far as I know, accepting the call (by VoIP, land line, or cell phone) shouldn't pose any threat.
What they want you to do is to allow them to remotely login to your PC and "fix" your machine for you. That is so obviously a security threat that I'm surprised anyone falls for it, but I'm sure enough people do that it pays them to call me at least once a month hoping I'll fall for it that day. (Even though I don't have any systems in my house running a Windows OS, and it is impossible to follow their directions to give them remote access.)
Thanks, Don, that confirms what I thought / felt, but I'm too ignorant when it comes to VoIP that shares a common line and addresses with data, via my provider. I hope I can trust them when they assured me of their safety precautions, covering VoIP as well.
What I heard, is that these fake MS support impersonators try to get you to download their "patch" or software in the hope that you execute it on your system.
So this seems like a crude and straightforward tactic that can be seen from miles away and I would not worry too much about it.
I agree with all that's been said. I've been involved with VoIP for some time and you can get paranoid about it.
So, without trying to cause any anxiety, I'll try and upload an attachment with a document about this issue (which is still available on the web somewhere) if it will let me, but I wouldn't worry too much.
Thank you, hicksd8, for the link. Massive interesting tech info, and a small chapter on what interested me most:
Unfortunately, the countermeasures proposed can't be done locally but have to be left to the provider (which I expect they do).
I'll stick to keeping ports closed and activating the firewall on the router.
I just rely on my router port forwarding forcing VoIP packets to only to go my (relatively dumb) SIP phone. Like you, I don't know much else can be done.
I recall VoIP vulnerabilities over the years and for many years.
On another note, it is always important to keep in mind that (IT) RISK is the intersection of VULNERABILITY, THREAT & CRITICALITY.
So, even if there is a VULNERABILITY, if there is no real THREAT or CRITICALITY, then RISK is LOW.
For example, for someone who uses VoIP and is not a high profile person or spy or criminal etc who has THREATS and if a VULNERABILITY is exploited, it does not do critical harm (in the case of VoIP threats for most people who use VoIP daily), then the RISK is low.
I've been aware of possible VoIP exploits for many years, but it does not stop me from using the myriad technologies that use VoIP. This especially applies to VoIP technologies which are encrypted. LINE, What's App and I believe Skype are all encrypted and so exploiting these VoIP vulnerabilities are non trivial, as I recall, and so most users who use encrypted VoIP are not at high RISK.
There is also the RISK MITIGATION model, which combines TECHNICAL (LOGICAL) CONTROLS, PHYSICAL CONTROLS AND ADMINISTRATIVE CONTROLS, should be considered as well
Encrypting a VoIP channel is a TECHNICAL CONTROL and having a policy whereas HIGHLY SENSITIVE USERS do not use these apps unless approved is an ADMINISTRATIVE CONTROL.
It is important to keep in mind that RISK MANAGEMENT and RISK MITIGATION is a multidimensional and multifaceted approach, so VULNERABILITIES must be viewed in context to the THREAT and CRITICALITY; and RISK MITIGATION must be viewed in terms of RISK and the "best" combination of controls (ADMIN, TECH, PHYSICAL) based on RISK (and this implies budget as well).
Not sure if this is relevant to you or this thread but we dealt with EADS several years ago and they tore Skype apart for its obfuscation and untrustworthy code: