A Pentester's Prespective: SWIFT Vulnerability Assessment
Table Of Contents
Before we begin assessing the security of SWIFT infrastructures, we must first understand the architecture and components of it. Let us begin with the components involved for SWIFT operations. SWIFT is made up of various categorized components, as shown in the header image above.
Local SWIFT Infrastructure
SWIFT Secure Zone: It is a segmented area that divides SWIFT-related systems from the rest of the environment. This zone, however, can also include non-SWIFT systems.
Messaging Interface: It is an interface that supports the MT, MX, or ISO 20022 message standards that enables users to connect the SWIFT FIN, InterAct, FileAct, and SWIFTNet Instant messaging services directly to the communication services
Communication Interface: It is a software program that provides the communication link between the Messaging Interface Software or a back-office system and the SWIFTNet network.
SWIFTNet Link (SNL): It is a software program used to access FIN, InterAct, and FileAct messaging services**.**
Connector: It is a software program that provides the communication link between an external messaging interface, a communication interface, or a service provider.
Graphical User Interface (GUI): It is a software program that is responsible for providing a graphical interface for messaging and communication interface.
Operators
Operators are the personnel (end users/administrators) responsible for interacting with the SWIFT infrastructure directly.
Operators PCs
There are generally two types of Operators PCs on the SWIFT infrastructure
General-Purpose Operator PC: It is located outside of the secure zone or in the general IT department for performing daily business activities.
Dedicated Operator PC: It contains primary and secondary PC which are located in the secure zone and interact with the components in the secure zone.
Data Exchange Layer
A layer that is responsible for transferring data between a SWIFT secure zone and a user back office.
Middleware Server
It is considered a customer connector used to provide a connection between SWIFT components and external connections. For example, service providers.
Architecture
- A1 Architecture: This is an architecture when a messaging interface and communication interface are owned by an user environment.
- A2 Architecture: This is an architecture when an messaging interface is owned by an user environment but not communication interface.
- A3 Architecture: This architecture contains SWIFT connector on user environment and messaging and communication interface, GUI on a service provider.
- A4 Architecture: This architecture contains customer connector (example file server) on a user environment and all remaining components are located on a service provider.
- B Architecture: This architecture does not contain any of the SWIFT components on the user environment.
Assessment Approaches
Approach - I
The initial approach of performing a security assessment on the SWIFT infrastructure is to detect and exploit misconfigurations and vulnerabilities from outside the SWIFT network, which means the assessment is carried out via numerous networks outside of the SWIFT secure zone.
Scoping: It is a process of listing all of the components within the SWIFT infrastructure, as well as the IP addresses and networks that have been assigned to them. In General, there would be one primary PC, one secondary PC, one live server, one fallback server, and a network printer.
Reachability: It is a technique for identifying whether the SWIFT infrastructure is accessible from the organization’s other internal networks. Other networks should not be able to communicate with the SWIFT infrastructure because it is designed to be isolated from them. If the SWIFT infrastructure is available, it can serve as a starting point for the testing process.
- Connect to different internal networks of an organization.
- Use the tools like NMAP, Traceroute, netdiscover, etc., and scan the SWIFT network.
Information Gathering: Once the reachability is verified, we need to identify the live hosts on the SWIFT network, as well as the services/ports that are running on it. There can be situations when the host is active but there are no defined SWIFT components on it. We must also confirm the kind of live hosts on the network and their purpose.
Vulnerability Scanning: After gathering all of the essential information about the network, we can scan for vulnerabilities manually or automatically using tools such as Nessus, Nuclei, the Nmap vulnerabilities script, and many others.
Exploitation: SWIFT is a critical system, and indiscriminately exploiting the identified vulnerabilities could lead operations to being interrupted. An auditor must be certain of the implications of any vulnerabilities before exploiting them. The identified vulnerabilities can be exploited once all of the criteria have been understood by an organization.
Approach - II
Because the SWIFT network is designed to be isolated from other networks, it is not always possible to access it from other internal or external networks/departments and when the network is unreachable, it does not verify that the assessment is completed. The auditor/tester should test for the internal threats and vulnerabilities within the SWIFT network itself as well. For this, a tester should be able to connect with the SWIFT network and begin the assessment.
What should a tester look for while using this approach?
- Verify if the network allows an attacker machine to communicate on the SWIFT secure zone when the devices (like dedicated operator PC) on the network were replaced by an attacker device.
- Verify to see if the network has more than the required number of hosts up and running. There could be hosts running that do not have any SWIFT components installed; and if such hosts are vulnerable, the SWIFT secure zone could be affected as well.
- Verify that the device on the SWIFT network used for general purposes is accessible to other SWIFT devices and servers.
- Verify whether SWIFT and other departments are accessing the same file-sharing servers. If the server is shared with other departments too, users from those departments might have access to it.
- Reachability testing is carried out through the other internal networks/departments to SWIFT starting with Approach-I. A tester should also check whether or not other networks are accessible through SWIFT. Other departments, such as IT, may have access to the network, increasing the attack surface.
Once the above criteria have been checked, a tester could use several vulnerability scanning tools such as Nessus and NMAP to do vulnerability scanning on the SWIFT internal networks. Also, a penetration tester should be able to provide proper remediation approaches to the identified vulnerabilities in a documented format.
How Can CryptoGen Nepal Help?
CryptoGen Nepal, with a highly skilled professional in the Cyber Security domain, offers organizations the facilities to conduct a Vulnerability Assessment of SWIFT infrastructures as part of the SWIFT CSP v2022 Assessment.