From a modeling perspective, VPN solutions come in two flavors; network-to-network configurations and client-server configurations.
In both cases, an encrypted connection is set up between the endpoints.
VPN connections statically set up between two network zones allow any member of one network to make contact with any responding service in the remote network without additional configuration of the endpoints.
Of course, this setup is facilitated by configurations in both endpoint routers, or gateways, but if analyzing the respective endpoints' security statuses is not the main goal of the analysis, it is enough to model a network-to-network VPN configuration as a single ConnectionRule object.
If the configuration is set up to be initiated only from the Local Network to the Remote Network and not the other way around, the OutNetworkConnection and InNetworkConnection types shall be selected as below.
If instead the tunnel also allowing connections to be initiated from the Remote Network to the Local Network, the NetworkConnection connection type shall be selected for both connections.
If the VPN configuration is set up to allow any client application in the Local Network to access only a specific set of services in the Remote Network, instead of any service in the Remote Network, then the ConnectionRule shall be connected using InApplicationConnection to the specific allowed service applications.
In order to compromise the VPN connection, either of the end points need to be compromised.
VPN configurations based on a client-server setup, like for instance openvpn and other similar solutions, are not tied to a particular network on the client side. Instead the client application authenticates to the VPN server which then provides the network forwarding functionality.
The VPN service is represented by a RoutingFirewall object that with a VPN Network Network object and a VPN-Network ConnectionRule object. The VPN Network object is representing the local network/ip-address pair that is set up between the VPN client and the VPN server when the connection is established and the VPN-Network ConnectionRule is representing the actual traffic forwarding.
The VPN Service is connected to the Public Network via NetworkExposure (since anyone with the correct credentials can connect to it).
The VPN Service has an Identity object connected to it, labeled VPN User Identity. The credentials allowing to authenticate to the VPN Service are located in the VPN Client's configuration. In reality these better be stored somewhere else or have MFA enabled, but for testing the VPN logic, this is a decent assumption.
The complete model with no labels displayed is shown below.
In order to try the model out, an Attacker has been connected to the model with Access to the Local Network and with AttemptSocialEngineering to the Regular User (which is allowed to use the VPN Client).
As an effect of a successful soacial engineering attempt, the attacker has succeeded with impersonating the Regular User's Identity in the workstation. This lead to the possibility to read the configuration of the VPN Client where the necessary credentials are found.
Next, being able to authenticate to the VPN Service provides access to the VPN Network (the network set up by the VPN Service once the user is authenticated.
Finally, having gained access to the VPN Network provides access to the ConnectionRule allowing access to the Remote Network (the VPN protected zone).
The complete attack path is as follows.
Updated 8 months ago