Eavesdropping inside a VPN network (from the inside)

anquietas

Hello,

I am currently researching security inside VPN networks and I have a very interesting question for which I need a clear and professional answer.

The very definition of a VPN, in popular culture, sounds something like "a virtual private network is a network behaving like a local LAN, but operating over public infrastructure, like the Internet, for example, providing security in the form of authentication and confidentiality".... or something like that :-)

OK, so far so good, I got the picture.

But, as you know, even if you are on the same LAN subnet and you want to communicate with someone on your LAN, if you are using unencrypted protocols (plaintext protocols), somebody could eavesdrop on you if the LAN switch broadcasts frames to the wrong ports, and the listener sets its LAN card to promiscuous listening mode.

My question is:

In a VPN network, which, in my case, is made up of 5 members, each connecting to a central OpenVPN server (which has the "Client-to-Client" option active in its configuration), if I (node Alpha) communicate with node Beta over an unencrypted protocol like plaintext FTP or VNC, could someone that is also connected to the VPN Server (let's say, node "C") intercept and understand my communication, like in a real LAN, for example ?

Also, please note that I am NOT referring to outside-of-the-vpn eavesdropping !
An outsider can only intercept encrypted packets while trying to listen to VPN packets.

I am strictly talking about eavesdropping from someone who is already inside (or connected) to the same VPN network as I and my partner, with "client-to-client" option active.

I hope I made some sense...

Also, please, do NOT reply with a speculative answer, unless you clearly know and understand what I am talking about and you can motivate your answer. When replying, if you can, please try to give a reason for your answer. I am very interested in the inner workings of the OpenVPN protocol.

With all due respect to all who want to help, please, I only need a clear, 100% correct, proven answer, I do not want speculations if you are not sure about the answer to this question.

Thank you !

SomeGuy

[VPN Server (Charlie)]-(public-network-interface)----[Switch]----[Router1]----[Internet]
[VPN Client Alpha (Alice)]-(public-network-interface)---[Switch2]----[Router2]---[Internet]
[VPN Client Beta (Bob) ]-(public-network-interface)---[Switch3]----[Router3]---[Internet]
[VPN Client "C"? Why not Gamma? (Eve)]-(public-network-interface)---[Switch4]----[Router4]---[Internet]

* All [Internet] are connected.

General Assumptions:
Alice, Bob, and Eve all have unique and valid keys for being on the VPN.
Alice, Bob, and Eve all have full-chain validation of certs up to valid root cert for key validation, and checksums validation in vpn configs.
The OS use and rely upon properly configured DNSSEC for domain name lookup validation for "--remote" lookups, and enforce validation.
All DNS lookups from Alice, Bob and Eve only use a DNS service on the VPN -- no leakage in requests outside the VPN.
Alice, Bob and Eve all use their VPN to browse the Internet -- all their traffic flows through the VPN (Charlie.)
Charlie has full chain validation from valid root to any valid intermediates to valid signer to validate each unique key used by Alice, Bob and Eve unless other wise stated below.
Encryption is being used, and will, for sake of example, be assumed to be properly implemented without vulnerabilities, and the protocols also without weakness.

Example 1:
Alice and Bob are on the VPN. Either one is running a service using plain-text service. The other connects through the VPN and only through the VPN to use the service from the other. All 4 parties do not share the same subnets or VLAN when establishing connections through to the VPN, and none have direct access to the subnets the other is using.

Assuming the interface is "TUN" and not "TAP" and the clients and servers are properly configured, without malicious modifications to routing, and proper network filtering to prevent members from interfering with the routing between VPN users, the communication between Alice and Bob using Charlie is encrypted through the public media.
Alice, Bob and Charlie can sniff communications sent and received to each other.
Eve has no visibility to this traffic, and because Eve has no access to direct participation in any of the public subnets used by Alice, Bob, or Charlie, can't even sniff the encrypted traffic.

Outside of OOB, or side-channel/side-band attacks against Charlie, Eve should have no indication that Alice and Bob are communicating through Charlie.

Example 2:
Just like Example 1, but some differences:
1) All are sharing the same certs, CN, and private keys, because the VPN admin does not care about security, they "just want it to 'work'" with the least effort, and they just give the same cert/key out to all users.
2) Eve is able to share the same subnet as either Alice or Bob
3) Eve is able to force the switch port in-use to monitor, and act like a simple repeater/hub instead of a switch

Eve may be able to use all of this to sniff traffic from Alice or bob which is encrypted, and decrypt it, depending on other crypto configs.
This is a high risk Example.

Example 3:
Just like Example 1, but:
1) Using "tap" instead of "tun"
2) No firewall/filtering rules between clients is imposed by "Charlie"

I do not know, but would expect many of the same risks for members of a tap-subnet of eavesdropping as members that share a Layer 2 Switch VLAN/subnet. I see tap as a source of greater risk to network leakage of information than tun.

If there are no features you absolutely need in tap, why not just use tun?

Maybe you can get someone else to answer this for when tap is used; I do not use tap interfaces with OpenVPN.

More examples are possible, such as sharing the same LAN and attacking DHCP client requests to harm a client like Alice or Bob on their network. Same with NTP or other client service attacks to "own" their OS. Once Eve is able to exploit the OS, and gain administrative controls on the OS of Alice or Bob, then Eve can read, in the plain, the data being sent through the VPN tunnel. This does not even include the DoS attacks which are possible.

VPN are like SSH, in that they are designed to protect secure systems communications over hostile networks. If any member that is participating in the communication session is no longer secure, but infiltrated, the foundation of the purpose is undermined and invalidated. The most serious to infiltrate would be the VPN Server itself as it can watch all VPN traffic that passes through it; if Eve "owns" the "Charlie" then Eve has access to in-VPN communications between Alice and Bob.

HTH
-SomeGuy

anquietas

Wow !
Now that's a complete and very convincing answer ! Thank you !

From what I understand, the third user cannot intercept anything because all the traffic is relayed trough the VPN Server.

For the sake of the example, I shall describe my situation, which is exactly like you described, minus the fact that the users are not accessing the Internet trough the VPN.

The users are sometime in the same physical LAN, and sometimes are in different physical LANs.
The insecure VPN Service only binds itself to the VPN IP and furthermore, a firewall protects incoming VNC requests, by allowing them only from the VPN network (172.16.0.0/29) on that particular port. (TCP 5900)

All clients are connected to the VPN Server "Charlie" (172.16.0.1) via a TUN connection, and all get a private IP address for the VPN network:
172.16.0.1 - Charlie
172.16.0.2 - Alice
172.16.0.3 - Bob
172.16.0.4 - Eve

Charlie has the "client-to-client" set and no default routing trough VPN. Users are accessing the Internet on their own connection.
Alice hosts a VNC Server, listening only on the socket: 172.16.0.2:5900
Bob connects to: 172.16.0.2:5900 from his 172.16.0.3 IP address via the insecure VNC connection.

My question was, if 172.16.0.4 (Eve) can somehow intercept this, by listening in the VPN network, if the server has "client-to-client" option enabled, in order to steal the VNC password and connect to Alice.
Of course, from outside the VPN, the everything is encrypted. But from inside the VPN ?

Thank you !

SomeGuy

Everyone is on a separate LANs, and the previous conditions including no compromised OS, perfect crypto config, protocol, and implementation, and this is for tun interfaces not tap interfaces, and no modifications to routing on Charlie, Alice or Bob by Eve, and no duplicate keys/certs, etc.? Eve will not the see the VPN-only VNC connection between Bob to Alice. (In this case, there is no Layer2 MAC discovery over the VPN, as is found on ether-switches with ARP/RARP and layer3 broadcast - the "Charlie" knows where to reach each possible destination IP on its VPN tunnels and when properly running, only send packets for a destination to just that destination.)

Once you modify this by allowing Eve to be on the same subnets as Alice or Bob? There are increased risks to break some assumptions.

What if Eve is on the same network as Bob?

Consider that Bob is using DHCP to get his IP address on his LAN and Eve is also on this LAN. It is possible for Eve to run a DHCP server, and support routing/NAT, and when Bob requests an IP address or renewal, Eve could get a DHCP response to Bob before the "real" DHCP server. In this case, Eve could include IP address information and routes that overlap the routes that the VPN server may push. Bob needs an IP address before Bob can get on the VPN. (Additionally, Eve could attack the DHCP client on Bob's machine by passing DHCP extensions/options that alter Bob's network settings, or attack vulnerabilities in Bob's DHCP client, but that is beyond the scope of this discussion, and assumptions in my previous post.) Similar issues exist with NTP. Eve could run a bogus NTP server and include her NTP server in the DHCP response to Bob, and ensure that the time that bob has to "too far off" of "real" time, to prevent Bob's VPN client from being able to establish a VPN link through to Charlie. (Also, beyond scope here, controlling "time" on Bob's box introduces even more attacks on the crypto.)

Using the above, if Eve is on the VPN, and allows routing of Bob's non-VPN traffic to pass through Eve, and has convinced Bob to use Eve as Bob's default Gateway, and Bob is not using Bob's VPN tunnel because Eve is preventing it, then it is possible for Bob to be at risk of not actually being on the VPN through Bob's VPN tunnel (VPN service broken on his box) but for Bob's Internet traffic to route through Eve and to access the VPN IP used by Alice by Bob running Bob's traffic through Eve (acting as a router with DHCP information passed to Bob, using Eve's VPN connection to the VPN) in order to watch Alice and Bob's VNC communication. In this case, if Bob does not observe Bob's tunnel is down, but tries to connect through Eve (in the plain) who uses her (Eve's) VPN link to relay to Alice, the VNC connection may actually happen, and happen through Eve, allowing Eve to watch the connection as a MitM.

There are even more attacks possible when attacker (Eve) is on the same subnet as Bob.

Level of complexity in attacks should not be considered as a limiting factor to the attacker needing to possess the skills needed to understand the attack; any attack, including complicated attacks, can be scripted and automated for incompetent or unskilled users to use. (If someone can imagine an attack, and someone can create an algorithm that describes the attack, then the attack can be automated... Generalization then risks availability as a plugin for attackers to play with, without understanding how it works.)

A common method for mitigating some of these risks include:
* Blocking all Internet traffic (IPv4/IPv6) from OS (Bob or Alice) except for what is needed to establish a VPN connection.
* When VPN is down, access to the Internet is down.
* When VPN is up, all traffic passes through the VPN (except what is needed to start/maintain the VPN link.)
* Educate Bob in verifying the VPN is up before trying to connect to VPN-only resources
* Once on the VPN, only use NTP updates from/through the VPN
* Generally a good idea: Once on the VPN, only use DNS through the VPN

This does not defeat all attacks against VPN users on the same subnet; this example is meant to illustrate difficulties when an attacker (Eve) is on the the same subnet as Alice or Bob.

anquietas

Thank you for your wonderful and complex and detailed and full-of-passion answer !

You would make a great teacher !