Hot answers tagged

56

You haven't actually provided enough details to say one way or the other. The fact that you didn't see an authentication prompt doesn't preclude there from being one. The remote access tools I use in my job (which also deals with HIPAA) both require me to authenticate with my domain admin credentials and do not prompt users to accept the connection, ...


27

HIPAA does not get to specifics of policy, the substance of it is that organization have to have sufficient controls in place to protect data. There's nothing inherently wrong with an unprompted takeover from a HIPAA perspective, as long as other controls (authentication, authorization, access control lists, access logging and auditing, antimalware on the ...


26

There's a couple of differences between using a 3rd party supplier (such as teamviewer) and a direct remote control solution (eg, VNC) Team Viewer has advantages in that it doesn't require ports to be opened on the firewall for inbound connections, which removes a potential point of attack. For example if you have something like VNC listening (and it isn't ...


24

Running Teamviewer isn't very secure: read here To determine who was logged in - look here: C:\Program Files\TeamViewer\VersionX\Connections_incoming.txt C:\Users\XXX\AppData\Roaming\TeamViewer\Connections.txt


23

The host machine can impact and alter whatever it wishes in the guest VM. The host can read and write all the memory of the guest, stop and restart it on a per-instruction basis, and, by nature, sees every single data byte which enters or exits the guest. There is nothing which the OS in a guest VM can do to protect itself against an hostile host. Thus, if ...


18

Take a look at this security analysis of TeamViewer. In short, it's definitely not secure on untrusted networks: https://www.optiv.com/blog/teamviewer-authentication-protocol-part-1-of-3 Conclusion: It is my recommendation that TeamViewer not be used on an untrusted network, or with the default password settings. TeamViewer does support increasing the ...


16

I just want to add an answer which I think hasn't been touched upon yet. When you connect via teamviewer to another computer, you share your clipboard with that computer (by default). Therefore, everything you copy onto your clipboard is also copied onto the clipboard of the computer you are connected to. By installing a clipboard tracking application such ...


16

It's high likely that your computer has been compromised, probably by a RAT which you caught by drive by download or email attachment. Unless you are a very technical person, I strongly advise the following: Do a malware scan on the system because the attacker probably installed more malware after entering the system (Pro tip: Live boot a Linux system and ...


14

From their own FAQ: Q: Has your secure datagram protocol been audited by experts? A: No. Mosh is actively used and has been read over by security-minded crypto nerds who think its design is reasonable, but any novel datagram protocol is going to have to prove itself, and SSP is no exception. We use the reference implementations of AES-128 and OCB, and we ...


13

To elaborate on ewanm89's post, TeamViewer does use UDP pinholeing. UDP is a stateless protocol. This means packets are fired off at their target with no verification (at the protocol level) that they were received or even reached the destination. Firewalls are designed to look for UDP packets and record the source and destination as well as the timestamp. ...


13

This is a good question! First a disclaimer that I'm not really qualified to give a complete answer, as I have so far been fairly good at avoiding RDP security issues in untrusted environments. I do use both RDP clients and servers though, but only ever on trusted hosts. That said, I do have a few thoughts why we're seeing such warnings; It would be fairly ...


11

Very frightening! As a risk, this should be raised to the board - effectively an attacker on the internet only needs to find out that username and password (or an SSH 0-day) and your entire corporate network should be considered compromised. Could the business run without it? Is there anything sensitive on it? This is a bad idea in so many ways: It ...


11

When you say "Welcome" screen with all users listed. Is that so, or is it one named user and then "Other user"? If it is one named user and "Other user" then the named user is actually coming from the RDP client and is not being exposed. Depending on which client you are connecting with, but at least the Win XP client will save last connected user on the ...


11

Despite outrageous marketing claims to the contrary, antivirus software is not smart. Antivirus does not recognize "types" of software, as in "mmh... this looks like a tool for RAT". There are strong theoretical reasons why this sort of detection is, in all generality, impossible to achieve, and correspondingly very hard to do in practice. What antivirus ...


10

If you are using SSL, see this technote for details. In particular, it is important to set up your security layers The three available security layers are: SSL (TLS 1.0) SSL (TLS 1.0) will be used for server authentication and for encrypting all data transferred between the server and the client. Negotiate The most secure ...


9

If users must have SSH to your server, a useful tool to protect your server root is chroot - this will let you give them the apparent functionality of server root, without actually giving them the crown jewels. Alternatively, as you use virtual machines anyway, why not provide them with virtual server instances? Both of these will allow you to run ...


9

It turns out my previous assumption was correct. These DDoS "attacks" are actually a side-effect of a Makost[dot]net-style botnet and is NOT the intention of the attacker (in fact, they seem specifically designed NOT to cause a disruption of service which would make us aware of their activity). The attacks are in fact trying to gain access to my servers in ...


8

It all comes down to the threat model. It depends on the risks and the likelihood of an attack. It depends on what the workstation does. It depends on the clients involved. How is this any different from running SSH on an actual server? If the service account doesn't have permissions to do much then the attack can't get very far. If the service account ...


8

By "open on their router" I assume you mean open to the Internet. I'd advise against this. Remote Desktop Protocol is susceptible to known attacks. Also you say "patched", but even as recently as last week Microsoft issued a security bulletin against RDP: This security update resolves two privately reported vulnerabilities in the Remote Desktop ...


8

As often with security, the answer to that is "maybe". In theory, if setup right and if you're keeping your system up-to-date, RDP is actually quite secure. Possibly not the most secure system available but still it can be considered secure enough for most usage (and can be extended if necessary). The first and most relevant issue you will encounter with ...


7

Update: The question has since it was originally posted been edited to highlight one difference, namely that RDP v6 over TLS is used. While the answer may still be considered "okay", I must now argue that tunneling TLS over SSH is unnecessary due to a lack of relevant and likely threat-scenarios - assuming correct configuration of TLS certificates etc. In ...


7

If you are connecting to localhost (127.0.0.1) on an ssh forwarded port (the 5901 your forwarded), then yes your connection to the remote host is encrypted.


7

You can also restrict users to using bash 4 (removing other shells) and record all commands and send copies to a separate log server. Bash: History to Syslog (http://blog.rootshell.be/2009/02/28/bash-history-to-syslog/) This can help you audit user activities and, more importantly, perform forensics when someone does something bad. I would also do the ...


7

If you have no liability for what the users do with the laptop, then what is the benefit to you of monitoring the usage. In the absence of any legitimate benefit, that would leave anyone questioning your motives in doing so - so you would create liability by doing this. There are a lot of other security concerns you should be concerned about - primarily ...


7

Basically it is not safe. As far as I know, they use 512-bit RSA because they mimic what Microsoft's RDP server used to do, which indeed implied a 512-bit RSA key; using something bigger would risk breaking compatibility with existing clients. Biggest issue, though, is not that the 512-bit key is weak because too short; the main problem is that, as a client, ...


7

Yes it's possible. An obvious example would be a Remote Access Trojan (RAT). Once your computer is infected they can do essentially whatever they're set up to do. This includes monitoring your screen, logging keystrokes, and accessing webcams. My personal experience with this was being infected with the Blackshades RAT a few years ago. I was monitored for ...


6

On one hand, it increases the attack surface, on the other it increases manageability. So, it could be a net positive for the risk profile if that's what's being used to manage systems and apply updates. In this particular case, it's just for convenience, and it's on a high risk target. The questions here need to be: Is the risk worth it for the ...


6

Bear in mind that any local apps which are able to connect to localhost will have no barrier to attacking the listening vnc service, so at a minimum still ensure vnc auth remains enabled.


6

Do not forget about tunneling, port forwarding. By default AllowTcpForwarding is yes in sshd_config file and it allows users to forward arbitrary ports. It may cause much more trouble than you can guess. (This is not an ideal stackexchange style answer but I could not find a better answer, it's hard to summarize port forwarding with a few sentences) You ...


6

You shouldn't be worried about it. It looks as if Teredo is a IPv6 tunneling technology. According to this Wikipedia article it allows for IPv6 connectivity by tunneling IPv6 packets through your router encapsulated in IPv4/UDP datagrams (so you can still talk IPv6 even though your router doesn't).



Only top voted, non community-wiki answers of a minimum length are eligible