Setting up to learn more about your Remote Desktop Software
This is a self help lesson guide which will require knowledge of firewalls beyond Windows firewall and Firewall logs. It's also a fun project that helps understand how stuff works.
How your Remote Access Application Works (Research Test)
One of the most searched articles I have is about the TeamViewer Hack I found years ago. Now, it’s all good because I was at fault for finding this issue.
You might remember the 20 minute timeout that the free version had.
Well, let’s say you could connect for days using the free versions with a simple firewall trick that isn’t hard to do. The testing I did disclosed the weakness and I’m sure many applications today have similar issues.
Let me give you your assignment so you can do your own testing and report your discovery.
This is for fun so make sure your friends computer is good to go and your friend knows you are going to be testing. You’ll actually need two people to complete the test.
Computer A to Computer B Remote Desktop Connection using any software on the market.
- Firewalls, we need good firewalls. This can be Tiny Personal Firewall or any firewall that allows you to block all ports and open ports one by one and be able to do that with both inbound and outbound connections.
To test your Firewall and if it’s going to be good for you lesson let’s set it up to block everything right now. If you can ping, www, smtp, telnet you haven’t blocked everything. Get that test done without using that dang panic block which will not help you later.
- Now that you have your firewalls setup on both ends. (Did I forget to tell you that? Ok, skip the remote for now but you’ll need it done as well.) Let’s move to the software. Run the Remote Desktop Software of your flavor with your firewall completely locked down but logging. Look at the connection attempts and look at the application. Once you see the application you need to keep your eye on that and the number of times it will appear if more than once and under what conditions it runs more than one process. (VNC dual Server = 2 Processes)
- Your first setup is to get an idea of how the software searches for open outbound ports. It will or should attempt TCP and UDP in a random but also good known port to be open process. Remember, they calm it’s fast so they can’t search every port.
- If you find only 4 or 5 ports are probed and the software just goes idle then it’s detecting no connection to the internet and should popup a warning. (Try it, it will happen with most software.)
- Ok, with a list of the ports it attempted to use now we need to open just one and only in the outbound direction.
- Record the IP address and if your firewall identifies a return or inbound connection attempt from this same IP or others. In some cases the inbound might be pooled so you’ll find server1 attempts, server2 attempts, server3 attempts then it repeats a couple of times then fails the connection and should offer you a message.
- With a list of your Outbound connections and the probed inbound connections add one inbound connection IP and launch the application again.
- You should be good once it does its search.
- Now you have control over what that first server sees and this is what I did to bypass the session timers. (Settings changes on my computer is not a hack it’s my right to block)
- Now it’s time to setup your remote system. I would suggest repeating the steps you did on your first computer if you have the same firewalls it would be even better. If you don’t you can proceed with a simple connection test. But remember, you need to be able to filter and identify in real-time every connection to understand how the remote desktop network service works.
- When you’ve completed the second computer setup let’s connect to it now. Looks good, act like you’re doing normal remote desktop stuff. Now, block on your side (viewer) the inbound connection from the session host server. Keep using your remote desktop and monitor the time it takes before your session is dropped. It might think something was wrong but this is what I found.
- When the inbound connection to my viewer system was blocked but the remote system (server) was still active and my session connection which was my outbound connection kept it alive. Now the server monitoring 2 connections only sees 1 computer connected and active with the session. (This is where the hack came into the remote unblocked system)
- When you blocked the Session but the session was still active and you were connected you can now see if outside session connection attempts are made. And believe me you will see them. Now, its unclear how the remote person got the session I watched but I can say for sure they didn’t know the session ID you see in your software because that’s the first thing they copied.
- Anyway, back to your lesson. Now that you have blocked one side your lesson is about timeouts and if you can get your computer to stay connected beyond the connection time limits.
I do believe this method would also work in the Pay Per Minute connection session monitoring servers. I’m not a member of a pay site so I can’t test and if you do test be sure you are ready to pay a big bill if it does monitor single session connections. (Route throughput would or could be bypassed but not direct single routed connections.)
I hope you have as much fun as I did testing years ago. I haven’t had time to setup my old XP with Tiny for the best of tests. But if you do find something interesting feel free to share it but don’t send me a link to your cracker site.
The new Knowledge Base from SmarterTools.com that I’ve been testing should start getting a few good simple guides to setup and testing. I’ll publish findings you all send in and offer up your iGoogle or other Social Media links to give you all the credit.
If I had time I’d test them all but it’s time consuming enough just testing what I use today.