75 comments

[ 4.6 ms ] story [ 147 ms ] thread
Is this from the 2016 hack or a new one?
Website lists October 14th, 2019 as the article date and quotes a tweet from four days earlier. So I'd assume it's new.
> Unfortunately, this is not the first time TeamViewer is the victim of threat actors. About four years ago...

Sounds like a new one.

Site is currently unresponsive. Cached version:

http://archive.is/bklNU

Has anyone noticed that archive.is has pretty apalling dns-based tracking?
They still refuse to serve users with Cloudflare DNS.
What do you mean by tracking?
check out the *.pixel.archive.is lookups
Fascinating, they embed a tracking pixel of: http://onion.[SOME_NUMERIC_ID].pixel.archive.today/pixel.gif for Tor endpoint (archivecaslytosk.onion) connections but https:// [YOUR_IP].[COUNTRY_CODE].[SHORT_ALPHANUMERIC_ID].[SOME_NUMERIC_ID].pixel.archive.is/pixel.gif for regular (archive.is/archive.fo/archive.today/etc) connections.

So at least this lets archive.is correlate your IP with your DNS server (which must pass EDNS Client Subnet to get any meaningful response, this is the reason why Cloudflare DNS is not that great for accessing archive.is; more: https://news.ycombinator.com/item?id=19828317).

There is something weird going on - both demanding the EDNS detail and then the extra tracking. I'm happy to avoid them using cloudflare's privacy stuff.
The article doesn’t give me any confidence in their reporting and is a site I’ve not heard of, so I’m feeling it’s a bit suspect. Anyone have a better source?
The article should've linked to this tweet[0] by the same researcher instead:

> "APT41 compromised company behind TeamViewer - which enabled them to access any system with TeamViewer installed"

[0] https://twitter.com/cglyer/status/1182413194360508419

Ok, we changed the URL to that from https://www.securitynewspaper.com/2019/10/14/fireeye-confirm.... Thanks!
The title could still be a bit better, the story is about the ability to access billions of devices. There is zero indication that billions of devices were actually accessed.
Sorry for the belated reply; I just saw this. I suppose "may have accessed" was intended to communicate that in the title?
I'm sure it was, I'm just not so sure that it does a very good job at that.

I feel like the most obvious interpretation of this is "APT41 possibly accessed billions of devices" which is incorrect, they had the ability but it is known that they only accessed a rather limited set of devices.

I'm not sure what would've been a better title though, especially given the length restrictions" ¯\_(ツ)_/¯

(comment deleted)
There is an ongoing trend the last several weeks of highly sensationalized cybersecurity incidents being mis-reported and ending up being nothing.

Not sure if it’s just a cluster of fuckups or if something is contributing to the uptick in false reports. But add this one to the list.

How do we tell if we are affected? Also, how could it do anything if TV isn't open?
This is from 2016. It's hard to say how you can tell without knowing what techniques were used against you specifically,if you have FireEye's network or endpoint products (or any other major vendor) they would provide coverage for any remnants of compromise by that threat actor.
Reposting what TheKnack said [0] as a top level comment, since this is important.

> The Chief Security Architect of FireEye posted this Tweet last week clarifying that there isn't a new compromise of TeamViewer, and the social media posts suggesting there is are misinterpreting a slide from a conference presentation.

> https://twitter.com/cglyer/status/1183210046093758464

[0]: https://news.ycombinator.com/item?id=21308518

There is a more official statement from TV as well. https://community.teamviewer.com/t5/Announcements/FireEye-cl...
> TeamViewer is safe to use

How often has that been true? TV has been hacked more than once AFAIK.

Just as safe as it always was! \(^O^)/
TV gives full access to computers through passwords and it seems it's not brute-force resistant. Think about how long an SSH server with password enabled and no autoban would last in the open...

Edit: nevermind, the attack is apparently through some malware.

> Think about how long an SSH server with password enabled and no autoban would last in the open

quite long? unless you're using a bad password I don't really see any risk other than filling logs from password attempts.

Most useless statement in the history of mankind.
Speaking of TeamViewer, do you know a good open source alternative that I can self host (I mean self host the relay server for NAT traversal). That is as easy to use? Works on windows, mac and linux? It should also be installable in a few slick with no network configuration required.
I haven't tried this, but I imagine a situation where computer A uses SSH to connect to VPS B and computer C connect to VPS B using SSH. If both SSH connections port-forward a VNC port, you can use VNC.
This is what I use. In Unix it just works (TM). If you have an ssh client in windows, it also works with Remote Desktop via ssh port forwarding. In lieu of a (configured) ssh client on Windows, you can send the other person a self-contained Go program to do the job.
Yes technically it could work, but I cannot ask the users to use SSH and configure VNC. The force of team viewer is that you download it, open it, and give number over the phone and it works.
Chrome remote desktop works pretty well
But for remote control, it stops after every few minutes, asking the "controlled" user to click on a button to continue. Not so practical in a few situations.
What do you mean? I've never had it do that.
It always happens for me when accessing a Linux machine remotely. I can't find a screenshot now, so the next time I do it, I'll take one. It seems to be a security measure, to prevent someone from sharing remote access and then forgetting about it afterwards, but it makes for terrible usability.
you can also port forward from/to unix sockets
I've been looking at a combination of SoftEther (for dynamic IPs) and Guacamole to replace TeamViewer, ConnectWise, etc.
I also use Guacamole for remote employee/vendor access (with public IPs hidden behind a proxy like an F5 or at least SSL+HTTP Simple Auth), but I haven't ever tried to configure it for remote support session sharing type stuff. Is that how you're using it? If so, how is it set up?
Anybody know of a UDP-based alternative? VNC is TCP.
Is there a reason why you need UDP specifically?
It's far smoother.
What protocol do you notice this with? In my experience, Microsoft RDP (the only protocol I know with configurable udp and tcp) with and without udp is imperceptible during typical use (eg. server administration).
With RDP. It's not imperceptible for me. I don't just use RDP for server administration.
Not OSS but remotedesktop.google.com works well.
It sucks for multi monitor setups though, keyboard events, defocuses for no reason, unlocks the computer you rdp into, doesn't support scaling monitors.
I don't know how smooth it is, since I haven't tried it myself yet, but apparently Nextcloud talk can do it. I think it needs a browser extension but that might not be nearly as much of an imposition as vnc + ssh. It's also pretty easy to self host on a vps or other server of your own.
(comment deleted)
zerotier.com is exactly this. I am still amazed how easy this is. (Big fanboy)
In case when remote control capabilities are not required, one could use jitsi (https://jitsi.org) video conferencing service which provides screen sharing capabilities (implementation depends on the web browser).

The main advantage is that there is no need to install any software neither on the remote machine nor on the local one.

There is a cloud hosted free version https://meet.jit.si which does not even require registration.

I use nomachine behind vpn and it works much smoother than teamviewer. It's multiplatform and free for personal use.
So I use TV for occasional family support.

Were machines vulnerable with only Teamviewer:

1. Installed but not being used? 2. Only when being used (i.e. ask family member to fire it up and give the connection info)

How would software that isn't running be vulnerable to random connection attempts?
If the software is not running when closed (system process) then it should mostly be fine.
Yeah, you never obviously know these days if there are background services running.
(comment deleted)
> This group of hackers uses highly sophisticated malware variants, primarily developed for espionage, so we consider it unlikely that any State is sponsoring its operations,” Glyer says.

> The web application security expert adds that, based on detected activities and attack methods, in addition to the unusual interest that APT41 has shown in attacking the video game industry, its attacks could not be politically motivated; instead, they’re focused on economic gains.

I’d like to know how can one simply assume this given a potential payoff of billions of devices...

Especially given that the "Video Game Industry" probably represents a pretty large group of heterogenous, idiosyncratic chat protocols, which I certainly would be interested in if I were the Chinese Govt.
TeamViewer devs are especially to blame for this. You can’t install it without admin permissions even if you just want to control another desktop. Unless you manually extract the .app from the .pkg, in which case it works fine.

Anyways, this isn’t the first time TeamViewer has been hacked. Wonder what their beef is against E2EE between connected computers.

On Windows it can be used by a standard user without being installed. It's much more difficult to do this on macos. Even on Windows there are dark patterns that make this difficult, but it can be done.
MeshCentral is open source, runs on Linux and works with Windows, Mac and Linux clients for one-off support and unattended remote control...
(comment deleted)
Thank you for the hint, I used AnyDesk (think it was built by people who worked at TV) but I'd enjoy an open source solution even more if it does what it should.
I've been using MeshCommander/MeshCentral (and their older tools like Open MDTK) since the first public versions, both for vPro/AMT related management tasks, and remote control. I'm very happy with them but I certainly won't rely on the assumption that they can't be hacked. With enough "motivation" an attacker has plenty of targets on the logistics chain where a vulnerability can be introduced (in the code, in the installer, etc.).
For a less sophisticated option for home users there's also DWService that is open source.