General description

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.

Network-to-Network VPN

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.

20492049

IPSEC-based VPN Tunnel between two networks.

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.

20382038

Bidirectional IPSEC-based Tunnel between two networks.

Network-to-Service VPN

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.

25892589

The ConnectionRule is connected using OutNetworkConnection on the Local Network side and InApplicationConnection to two of the three servers in the RemoteNetwork.

In order to compromise the VPN connection, either of the end points need to be compromised.

Client-to-Server VPN

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.

21172117

Objects and connections related to a VPN server.

The complete model with no labels displayed is shown below.

27352735

Client-Server-based VPN.

Attack Simulation

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).

UnsafeUserActivity

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.

17301730

UnsafeUserActivity lead to access to the VPN Client and access to reading the VPN Credentials.

Authenticating to the VPN Service

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.

19011901

Successfully authenticating to the VPN Service.

Gaining access to Remote Network

Finally, having gained access to the VPN Network provides access to the ConnectionRule allowing access to the Remote Network (the VPN protected zone).

13731373

Access to remote VPN-protected zone.

The complete attack path

The complete attack path is as follows.

27342734

The complete attack path.