I had been recently evaluating network capabilities of Microsoft Azure and found an undocumented reverse connection option that looked interesting to me.
It looks like there is a useful feature in the configuration of "Point-to-Site" VPN client of Microsoft Azure. This feature allows me to connect back from any Windows Virtual Machine running in my Microsoft Azure subscription to local VPN clients via RDP session.
It looks like there is a useful feature in the configuration of "Point-to-Site" VPN client of Microsoft Azure. This feature allows me to connect back from any Windows Virtual Machine running in my Microsoft Azure subscription to local VPN clients via RDP session.
I described my findings below.
Disclaimer
I have contacted Microsoft Security Response Center to elaborate if they see any vulnerability in the observed behavior. At the state on 25.8.2016 when I publish this article their answer was negative so I feel confident to share this information with developers/admins.
A response to my question from a senior Azure Architect at Microsoft was also negative:
"...really, this is speculation/subjective/opinion and would probably be closed there as well...".
OK, now I am confident this is not an unknown vulnerability, but rather an undocumented feature of Microsoft Azure.
Short description
A response to my question from a senior Azure Architect at Microsoft was also negative:
"...really, this is speculation/subjective/opinion and would probably be closed there as well...".
OK, now I am confident this is not an unknown vulnerability, but rather an undocumented feature of Microsoft Azure.
Short description
In regular conditions, a "Point-to-Site" VPN connection drops in the case when you try to connect back to a physical or virtual client machine that initiated this VPN connection, but as I found, it survives if the initial VPN connection was open INSIDE an RDP SESSION established to that physical or virtual machine!
Let me explain it in more details. below.
Initial conditions
Assume you have a Virtual Network ("VNET") in your Azure subscription with configured "Point-to-Site" VPN.
You have a Virtual Machine running Windows ("Azure VM"); it has Remote Desktop client ("RDP").
You also have a physical or virtual local machine with installed "Point-to-Site" VPN client for Microsoft Azure. Let's name it "Local PC #1".
You establish a Remote Desktop session from "Local PC #1" to "Azure VM"; let's name this connection "RDP Azure VM". You initiate and open a "Point-to-Site" VPN connection from "Local PC #1" to your "VNET" as usually.
As a result, you can connect to your resources hosted in Azure subscription using private IP addresses of "VNET".
Attempt to connect back #1
If you try to connect back from "RDP Azure VM" to your "Local PC #1" using RDP client of "RDP Azure VM" and IP address issued to "Point-to-Site" VPN client of "Local PC #1" the connection fails *. It happens because your "Point-to-Site" VPN session immediately disconnects as it should be (no shared connection allowed).
* You can easily find this IP address in a number of ways, for example:
- On the VPN client machine using "ipconfig" and exploring the section "PPP adapter <name of your VNET>".
- On the portal.azure.com under All resources > (your VPN gateway) > Point-to-site configuration > Allocated IP addresses (for Resource model VNET).
Changing to special conditions
Assume you have a second local machine, let's name it "Local PC #2", and you establish a Remote Desktop session from "Local PC #2" to "Local PC #1"; let's name this connection "Local RDP PC #1".
After that, you install "Point-to-Site" VPN client for Microsoft Azure inside the RDP connection "Local RDP PC #1".
You initiate and open a "Point-to-Site" VPN connection from "Local RDP to PC #1" to your "VNET" as usual.
As a result, you can connect from "Local RDP PC #1" to your resources hosted in Azure subscription using private IP addresses of "VNET".
Now please find and remember the IP address issued to "Point-to-Site" VPN client of "Local RDP PC #1".
Let's name it "Local RDP IP of VPN Client".
- Refer to the previous chapter to find this IP address.
Attempt to connect back #2
If you try to connect back from "RDP Azure VM" to your "Local RDP PC #1" using RDP client of "RDP Azure VM" and IP address issued to Point-to-Site VPN client of "Local RDP PC #1" ("Local RDP IP of VPN Client", see above) the connection somehow succeeds while there is still no shared connection allowed. As a result, you can access any available resources of "Local PC #1" and other machines of LAN from "RDP Azure VM" using RDP connection established to "Local RDP PC #1".
In my tests, I have successfully connected back to VPN Client machines at least on the following Windows editions:
- Windows 7 SP1
- Windows 2008 R2 SP1
-Windows 8.1, Update: a reverse connection seems to work only on the early editions of Windows 8.
As you can see, there is an unexpected and undocumented difference in reverse connection behavior between "Attempt to connect back #1" and "Attempt to connect back #2".
You have a Virtual Machine running Windows ("Azure VM"); it has Remote Desktop client ("RDP").
You also have a physical or virtual local machine with installed "Point-to-Site" VPN client for Microsoft Azure. Let's name it "Local PC #1".
You establish a Remote Desktop session from "Local PC #1" to "Azure VM"; let's name this connection "RDP Azure VM". You initiate and open a "Point-to-Site" VPN connection from "Local PC #1" to your "VNET" as usually.
As a result, you can connect to your resources hosted in Azure subscription using private IP addresses of "VNET".
Attempt to connect back #1
If you try to connect back from "RDP Azure VM" to your "Local PC #1" using RDP client of "RDP Azure VM" and IP address issued to "Point-to-Site" VPN client of "Local PC #1" the connection fails *. It happens because your "Point-to-Site" VPN session immediately disconnects as it should be (no shared connection allowed).
* You can easily find this IP address in a number of ways, for example:
- On the VPN client machine using "ipconfig" and exploring the section "PPP adapter <name of your VNET>".
- On the portal.azure.com under All resources > (your VPN gateway) > Point-to-site configuration > Allocated IP addresses (for Resource model VNET).
- On the portal.azure.com under All resources > (your VNET) > VPN connections > (n) clients > IP addresses (for Classic model VNET).
- A simple Powershell script that just iterates a potential set of IP addresses of your VPN pool accessible from "Azure VM".
Assume you have a second local machine, let's name it "Local PC #2", and you establish a Remote Desktop session from "Local PC #2" to "Local PC #1"; let's name this connection "Local RDP PC #1".
After that, you install "Point-to-Site" VPN client for Microsoft Azure inside the RDP connection "Local RDP PC #1".
You initiate and open a "Point-to-Site" VPN connection from "Local RDP to PC #1" to your "VNET" as usual.
As a result, you can connect from "Local RDP PC #1" to your resources hosted in Azure subscription using private IP addresses of "VNET".
Now please find and remember the IP address issued to "Point-to-Site" VPN client of "Local RDP PC #1".
Let's name it "Local RDP IP of VPN Client".
- Refer to the previous chapter to find this IP address.
- Note this IP address issued to "Local RDP PC #1" is different from the one issued to "Local PC #1" because technically there are two different VPN clients who established connections.
If you try to connect back from "RDP Azure VM" to your "Local RDP PC #1" using RDP client of "RDP Azure VM" and IP address issued to Point-to-Site VPN client of "Local RDP PC #1" ("Local RDP IP of VPN Client", see above) the connection somehow succeeds while there is still no shared connection allowed. As a result, you can access any available resources of "Local PC #1" and other machines of LAN from "RDP Azure VM" using RDP connection established to "Local RDP PC #1".
In my tests, I have successfully connected back to VPN Client machines at least on the following Windows editions:
- Windows 7 SP1
- Windows 2008 R2 SP1
-
As you can see, there is an unexpected and undocumented difference in reverse connection behavior between "Attempt to connect back #1" and "Attempt to connect back #2".
Options to use this reverse connection from Azure RDP to local RDP
The identified "feature" seems to open a wide area for imagination.
Fairly, the first thing I tested was establishing a connection from my office to Home PC. It perfectly works!
Take a look at my next article to see more opportunities.
Fairly, the first thing I tested was establishing a connection from my office to Home PC. It perfectly works!
Take a look at my next article to see more opportunities.
No comments:
Post a Comment