Information security of bank non-cash payments. Part 8 - Typical Threat Models

What research


This article completes the cycle of publications devoted to ensuring the information security of bank cashless payments. Here we look at typical threat models that were referenced in the base model :

• Typical threat model. Network connection
• Typical threat model. Information system built on the basis of client-server architecture .
• Typical threat model. Access control system .
• Typical threat model. Integration module .
• Typical threat model. The system of cryptographic protection of information.

HABRO-WARNING !!! Dear habrovchane, this is not an entertainment post.
Hidden under the cut 40+ pages of materials designed to help in work or school for people specializing in banking or information security. These materials are the final product of the study and are written in a dry official tone. In essence, these are blanks for internal security documents.
')
Well, the traditional - "the use of information from the article for illegal purposes is punishable by law . " Productive reading!

Information for readers who are familiar with the study, starting with this publication.

What research

You are reading the guide for the specialist responsible for ensuring the information security of payments in the bank.

Presentation logic

At the beginning of Part 1 and Part 2, a description of the object of protection is given. Then part 3 describes how to build a protection system, and talks about the need to form a threat model. Part 4 describes what threat models are and how they are formed. Part 5 and part 6 provide an analysis of real attacks. Part 7 and Part 8 contain a description of the threat model, built on the basis of information from all previous parts.

TYPICAL MODEL THREATS. NETWORK CONNECTION

Protection object for which the threat model is applied (scope)

The object of protection is data transmitted via a network connection operating in data networks built on the basis of the TCP / IP stack.

Architecture



Description of architectural elements:

• “End nodes” are nodes that exchange protected information.
• "Intermediate nodes" - elements of the data network: routers, switches, access servers, proxy servers and other equipment - through which the traffic of a network connection is transmitted. In general, a network connection can function without intermediate nodes (directly between the end nodes).

Top level security threats

Decomposition

U1. Unauthorized familiarization with the transmitted data.
Y2. Unauthorized modification of transmitted data.
Y3 Violation of the authorship of the transmitted data.

U1. Unauthorized familiarization with the transmitted data

Decomposition
V1.1. <...> implemented on end nodes or intermediate nodes:
D1.1.1. <...> by reading the data while it is in the node’s storage devices:
D1.1.1.1. <...> in RAM.
Explanatory notes for A1.1.1.
For example, during the processing of the network stack node.

D1.1.1.2. <...> in non-volatile memory.
Explanatory notes for D1.1.1.2.
For example, when storing transmitted data in cache, temporary files, or paging files.

D1.2. <...> implemented on third-party data network nodes:
D1.2.1. <...> method of capturing all packets that fall on the network interface of the node:
Explanatory notes for D1.2.1.
All packets are captured by putting the network card in promiscuous mode (promiscuous mode for wired adapters or monitor mode for wi-fi adapters).

D1.2.2. <...> by carrying out man-in-the-middle (MiTM) attacks, but without modifying the transmitted data (not counting the overhead of the network protocols).
D1.2.2.1. Reference: "Typical Threat Model." Network connection Y2. Unauthorized modification of transmitted data . "

V1.3. <...>, carried out due to leakage of information on technical channels (TKUI) from physical nodes or communication lines.

D1.4. <...>, carried out for installation on the final or intermediate nodes of special technical means (ITS), intended for covert information retrieval.

Y2. Unauthorized modification of transmitted data

Decomposition
B2.1. <...> implemented on end nodes or intermediate nodes:
B2.1.1. <...> by reading and making changes to the data while they are in the storage devices of the nodes:
U2.1.1.1. <...> in RAM:
U2.1.1.2. <...> in non-volatile memory:

Y2.2. <...> implemented on third-party data network nodes:
U2.2.1. <...> by carrying out man-in-the-middle (MiTM) attacks and redirecting traffic to the attacker's host:
U2.2.1.1. The physical connection of equipment intruders in the network connection gap.
U2.2.1.2. Execution of attacks on network protocols:
U2.2.1.2.1. <...> virtual local area network (VLAN) management:
U2.2.1.2.1.1. VLAN hopping .
U2.2.1.2.1.2. Unauthorized modification of VLAN settings on switches or routers.
U2.2.1.2.2. <...> traffic routing:
U2.2.1.2.2.1. Unauthorized modification of the static routing tables of routers.
U2.2.1.2.2.2. The attackers announced fraudulent routes through dynamic routing protocols.
U2.2.1.2.3. <...> automatic configuration:
U2.2.1.2.3.1. Rogue DHCP .
U2.2.1.2.3.2. Rogue WPAD .
U2.2.1.2.4. <...> addressing and name resolution:
U2.2.1.2.4.1. ARP spoofing .
U2.2.1.2.4.2. DNS spoofing .
U2.2.1.2.4.3. Making unauthorized changes to local host name files (hosts, lmhosts, etc.)

Y3 Infringement of data transfer

Decomposition
Q3.1. Neutralization of mechanisms for determining the authorship of information by specifying false information about the author or data source:
V3.1.1. Change information about the author contained in the information transmitted.
V3.1.1.1. Neutralization of cryptographic protection of the integrity and authorship of transmitted data:
Q3.1.1.1.1. Reference: "Typical Threat Model." The system of cryptographic protection of information.
E4 Creation of an electronic signature of a legitimate signatory under false data . ”
V3.1.1.2. Neutralization of the protection of the authorship of transmitted data, implemented using one-time confirmation codes:
Q3.1.1.2.1. SIM swap .

Q3.1.2. Change information about the source of information transmitted:
D3.1.2.1. IP spoofing .
D3.1.2.2. MAC spoofing .

---

TYPICAL MODEL THREATS. INFORMATION SYSTEM BUILT ON THE BASIS OF ARCHITECTURE CLIENT SERVER

Protection object for which the threat model is applied (scope)

The object of protection is an information system built on the basis of the client-server architecture.

Architecture


Description of architectural elements:

• "Client" is the device on which the client part of the information system functions.
• “Server” is the device on which the server part of the information system functions.
• The “data storage” is a part of the information system's server infrastructure intended for storing data processed by the information system.
• "Network Connection" is a channel for the exchange of information between the Client and the Server, passing through a data network. A more detailed description of the element model is given in the “Typical Threat Model. Network connection .

Restrictions
When modeling an object, the following restrictions are set:

1. The user interacts with the information system within finite time intervals, called work sessions.
2. At the beginning of each session, the user is identified, authenticated and authorized.
3. All protected information is stored on the server side of the information system.

Top level security threats

Decomposition
U1. Perpetrators of unauthorized actions on behalf of a legitimate user.
Y2. Unauthorized modification of the protected information during its processing by the server part of the information system.

U1. Perpetrators of unauthorized actions on behalf of a legitimate user

Explanations
Usually in information systems, the correlation of actions with the user who performed them is performed using

1. system logs (logs).
2. Special attributes of data objects that contain information about the user who created or modified them.

In relation to the session, this threat can be decomposed into:

1. <...> performed as part of a user session.
2. <...> performed outside the user session.

User session can be initiated:

1. By the user.
2. Intruders.

At this stage, the intermediate decomposition of this threat will be as follows:
V1.1. Unauthorized actions were performed during a user session:
D1.1.1. <...> set by the attacked user.
D1.1.2. <...> installed by intruders.
D1.2. Unauthorized actions performed outside of user session.

From the point of view of information infrastructure facilities that may be affected by intruders, the decomposition of intermediate threats will look like this:

Items	Threat decomposition
	D1.1.1.	D1.1.2.	D1.2.
Customer	D1.1.1.1.	D1.1.2.1.
Network connection	D1.1.1.2.
Server			D1.2.1.

Decomposition
V1.1. Unauthorized actions were performed during a user session:
D1.1.1. <...> set by the attacked user:
D1.1.1.1. The intruders acted independently from the Client:
1.1.1.1.1 The attackers used regular means of access to the information system:
1.1.1.1.1.1. The attackers used the Client’s physical I / O (keyboard, mouse, monitor, or touch screen of a mobile device):
1.1.1.1.1.1.1.1. The attackers acted during periods of time when the session is active, I / O facilities are available, and the user is not in place.
1.1.1.1.1.2. The attackers used remote administration tools (standard or provided by malicious code) to control the Client:
1.1.1.1.1.2.1. The attackers acted during periods of time when the session is active, I / O facilities are available, and the user is not in place.
U1.1.1.1.1.2.2. The attackers used remote administration tools, whose work is invisible to the attacked user.
D1.1.1.2. The attackers substituted data in a network connection between the Client and the Server, modifying them so that they were perceived as actions by a legitimate user:
D1.1.1.2.1. Reference: "Typical Threat Model." Network connection Y2. Unauthorized modification of transmitted data . "
D1.1.1.3. Malefactors forced the user to perform the actions specified by them, using methods of social engineering.

D1.1.2 <...> installed by hackers:
D1.1.2.1. The intruders acted from the client (s):
D1.1.2.1.1. The attackers neutralized the access control system of the information system:
D1.1.2.1.1.1. Reference: "Typical Threat Model." Access control system. U1. Unauthorized establishment of a session on behalf of a legitimate user . "
D1.1.2.1.2. Malefactors used regular means of access of the information system
D1.1.2.2. The attackers acted from other nodes of the data network, from which you can establish a network connection to the Server ( AND ):
D1.1.2.2.1. The attackers neutralized the access control system of the information system:
D1.1.2.2.1.1. Reference: "Typical Threat Model." Access control system. U1. Unauthorized establishment of a session on behalf of a legitimate user . "
D1.1.2.2.2. The attackers used non-standard means of access information system.
Clarifications D1.1.2.2.2.
The attackers could install a regular client of the information system on a third-party host or could use non-standard software implementing regular communication protocols between the Client and the Server.

U1.2 Unauthorized actions performed outside the user's session.
U1.2.1 The attackers performed unauthorized actions, and then made unauthorized changes to the information system operation logs or special attributes of data objects, indicating that the actions performed by them were performed by a legitimate user.

Y2. Unauthorized modification of the protected information during its processing by the server part of the information system

Decomposition
B2.1. The attackers modify the protected information using the standard means of the information system and conduct it on behalf of the legitimate user.
B2.1.1. Reference: "Typical Threat Model." Information system built on the basis of client-server architecture. U1. Perpetrators of unauthorized actions on behalf of a legitimate user . ”

Y2.2. The attackers modify the protected information by using data access mechanisms not provided for by the standard operating mode of the information system.
U2.2.1. Malefactors modify the files containing the protected information:
U2.2.1.1. <...> using the file handling mechanisms provided by the operating system.
U2.2.1.2. <...> by provoking the recovery of files from an unauthorized modified backup.

Y2.2.2. The attackers modify the protected information stored in the database ( I ):
U2.2.2.1. Attackers neutralize the DBMS access control system:
U2.2.2.1.1. Reference: "Typical Threat Model." Access control system. U1. Unauthorized establishment of a session on behalf of a legitimate user . "
U2.2.2.2. Malefactors modify the information, using regular interfaces of the DBMS for data access.

Y2.3. The attackers modify the protected information by unauthorized modification of the algorithms of the software processing it.
U2.3.1. The source code of the software is modified.
U2.3.1. Modification of the exposed software code.

Y2.4. Malefactors modify the protected information by using vulnerabilities in the software of the information system.

Y2.5. The attackers modify the protected information when it is transmitted between the components of the server side of the information system (for example, the database server and the application server):
B2.5.1. Reference: "Typical Threat Model." Network connection Y2. Unauthorized modification of transmitted data . "

---

TYPICAL MODEL THREATS. ACCESS LIMIT SYSTEM

Protection object for which the threat model is applied (scope)

The protection object for which this threat model is applied corresponds to the protection object of the threat model: “Typical threat model. Information system built on the basis of client-server architecture. ”

The system of delimitation of user access in this model of threats means a component of the information system that implements the functions:

1. User identification.
2. User authentication.
3. User authorization.
4. Logging user actions.

Top level security threats

Decomposition
U1. Unauthorized establishment of a session on behalf of a legal user.
Y2. Unauthorized elevation of user privileges in the information system.

U1. Unauthorized establishment of a session on behalf of a legal user

Explanations
The decomposition of this threat will generally depend on the type of user identification and authentication systems used.

In this model, only the user identification and authentication system using text login and password will be considered. In this case, we assume that the username is publicly available information known to attackers.

Decomposition
V1.1. <...> due to compromised credentials:
D1.1.1. Attackers compromised user credentials during storage.
Explanations D1.1.1.
For example, credentials could be written on a sticker pasted on a monitor.

D1.1.2. The user accidentally or by malicious intent gave access details to the attackers.
D1.1.2.1. User recited credentials out loud while typing.
D1.1.2.2. The user deliberately gave their credentials:
D1.1.2.2.1. <...> colleagues.
Clarifications D1.1.2.2.1.
For example, so that they can replace it for the period of the disease.

D1.1.2.2.2. <...> to the counterparties of the employer performing work on the objects of information infrastructure.
D1.1.2.2.3. <...> to third parties.
Clarifications D1.1.2.2.3.
One, but not the only way to implement this threat is the use of social engineering methods by hackers.

D1.1.3. The attackers selected the credentials by brute force:
D1.1.3.1. <...> using standard access mechanisms.
D1.1.3.2. <...> by previously intercepted codes (for example, password hashes) for storing credentials.

D1.1.4. Attackers used malicious code to intercept user credentials.

H1.1.5. The attackers removed the credentials from the network connection between the Client and the Server:
D1.1.5.1. Reference: "Typical Threat Model." Network connection U1. Unauthorized familiarization with the transmitted data . "

D1.1.6. :
1.1.6.1. <...> ( , ).
1.1.6.2. <...>
1.1.6.2.
— StuffCop .

1.1.7. - .
1.1.7.
, .

1.1.8. .

1.1.9. ():
1.1.9.1. , :
1.1.9.1.1 .
1.1.9.1.1
, .

1.1.9.1.2 , , .
1.1.9.2. (, Bluetooth).
1.1.9.3. ().
1.1.9.3.
.

1.1.9.4. (), .
1.1.9.4.
.

1.1.9.5.
Wi-Fi , .
1.1.9.5.
.

1.1.9.6. .
1.1.9.6.
.

1.1.9.7. .
1.1.9.7.
.

1.1.10. <...>, .
1.1.10.
, .

1.1.11. - .
1.1.11.
, .

1.2. <...> .

2.

2.1 <...> , .

2.2 <...> .

2.3. <...> - .
2.3.
1. , .
2. .

---

.

, (scope)

– , .

, , .


:



:

• « ()» – / / , .
• «» – / , , .
  «» , (enterprise service bus / SoA-), .. «».
• « » – , .
  , , ..
• « » , « ». , , .

1.

( , SQL-) (\\...\SHARE\) . - , .
— — .

, . - .

, , , - .



:
« » – .
« » – .
«» – .
« » – -.

2.

1, , (\\...\SHARE\) . - .



:
1, «» .

3. - IBM WebSphera MQ « »

, . ( ). .

.
- , IBM WebSphere MQ.

- IBM WebSphere MQ , — — .

- . IBM WebSphere MQ, .

. — — .



:
« » – .
« » — .
«» – IBM WebSphere MQ.
« » – -, .

4. API,

, ():

• « -» ( );
• « -» ( ).

, «».

.
, , . API , , , .

, .



:
« » – .
« » – .
«» – .
« » – , API , , API .

1. .

1.

1.1. :
1.1.1 : « . . 2. » .

1.2. :
1.1.2 : « . . 3. » .

1.3. :
1.3.1. : « . , -. 2. » .

1.4. :
1.4.1. : « . , -. 1. ».

1.5. :
1.5.1. <...> () .
1.5.2. <...> .
1.5.3. <...> .

---

.

, (scope)

, .


(), .

- , – .

, :

• / ;
• / ;
• - ;
• / / ;
• etc.

- :

• ;
• ;
• ;
• . .

- :

• , - (.DLL – Windows, .SO – Linux);
• , – (wrappers), , MS Crypto API, Java Cryptography Architecture, PKCS#11 . - , , . .

:

1 –


2 –


, , , .

, 1, (), , , . , , , . .

2, :

1. , . – « ».
2. , . – « ».

. , , «» — virtual HSM ( ).

, , , .

(API) , , . .

, , :

1. , (, -, .), .
2. , ( , .), .

:

1. - .
2. , , .
3. .

, , . .

1. .

. . , , , , .
: .

2. .
. . , . , . (, ). , .
: / .

3. .
. , . . , , . , . , .
: .

,

1. , , , API .
2. () , , .
3. .

,

.





(). , , , . Microsoft Office 2016, — .

1

1 , — . ruToken, . , , .

2

2 . .

: "\\...\In\", "\\...\Out\". "\\...\In\" . , .

"\\...\Out\" , , . .
, . , . (logs).

JaCarta , .

USB-over-IP, .

1 . 2 , , , .


IT- .

—

	1	2
	CSP	CSP
	missing	JaCarta
API	MS CryptoAPI	MS CryptoAPI
	: — ; — Windows.	: — . : — ; — Windows.
	ruToken,	JaCarta ,
	: — .	: — . : — .
	: — USB ; — .	missing
	( )	: — USB ; — ; — USB-over-IP; — . 2. : — ; — . : — ; — ; — USB-over-IP.
	: — -; — ; — .	: — -; — ; — ; — . 2. : — ; — ; — . : — ; — ; — .
	. 1. : — ; — ; — .	. 2. : — ; — ; — . : — ; — ; — .
	: — -; — ; — .	. 2, : — ; — ; — . : — ; — .
	AWP user: - I / O; - RAM. (CryptoARM graphic user interface)	Virtual machine: - RAM; - HDD. (Automation scripts)
Channel receiving results	AWP user: - I / O; - RAM. (CryptoARM graphic user interface)	Virtual machine: - RAM; - HDD. (Log files of automation scripts)

Top level security threats

Explanations

Assumptions taken in the decomposition of threats:

1. Strong cryptographic algorithms are used.
2. (, ECB , ..).
3. , .
4. .
5. .

1. .
2. .
3. , ().
4. .
5. .
6. .
7. .

1.

1.1. .

1.2. , .
1.2.

, , :

1. ,
2. ,
3. ,
4. ,
5. «» , , .

1.2.1. , (freeze attack).
1.2.1.
.

1.3. .
1.3.
.

1.4. , .

1.5. ().
1.5.
.

H1.6. Compromise of the private key as a result of the use of special technical means (ITS), intended for the secret collection of information ("bugs").

U1.7. Compromise of private keys in the process of storing them outside of SKZI.
Explanations D1.7.
For example, a user stores his key carriers in a desktop drawer, from which they can easily be extracted by intruders.

Y2. Encryption of bogus data on behalf of a legitimate sender

Explanations
. 1323565.1.004-2017 « . . » . , , .


2.1. :
2.1.1. : « . .1. » .

2.2. .
2.2.
.

3. , ()

3.1. .
3.1.1 : « . . 1. » .

3.2. .

4.

Decomposition
D4.1. Compromise of private keys of an electronic signature of a legitimate signer.
D4.1.1 Reference: “Typical Threat Model. The system of cryptographic protection of information. U1. Compromise of private cryptographic keys " .

Y4.2. Substitution of signed data in the open data exchange channel.
Note Y4.2.
Examples of the implementation of this threat are given below here and here .

V5 Obtaining a positive result of verifying the electronic signature of false data

5.1. c .

5.2. ( — ):
5.2.1. . , , .
5.2.2. , .
5.2.3. .

5.3. ( — ):
5.3.1. ( ) .
5.3.2. , .
5.3.3. .

5.4. ( — ):
5.4.1. .
5.4.2. . , , .
5.4.3. .
5.4.4. .

5.5. <...> 2- 3- :
5.5.
.

5.5.1. , , CRL OCSP.
5.5.1.
.

5.5.2.
5.5.2.
SSL/TLS .
e-mail. . , , , , .

5.5.3. .

5.5.4. CRL , .

5.5.5. , OCSP- , , , CRL.
5.5.5.
CRL, .

5.5.6. .
5.5.6.
. SSL-: CN .
. . , . , .

6. .

6.1. .
6.1.
. , , . , .

7.

7.1. <...> (side channel attack).
7.1.
.

7.2. <...> , :
7.2.1. , .

7.2.2. <...>, :
7.2.2.1. <...> .
7.2.2.2. <...> .
7.2.2.3. <...> .

.

1. 2.2 4.2.

Description of the object


The ARM CBD and SKZI SCAD Signatures are installed on a physical computer that is not connected to the computer network. PCF vdToken is used as the key carrier in the operation of the non-recoverable key.

The settlement procedure assumes that the settlement officer downloads electronic messages in open form (the old AWS KBR scheme) from a special protected file server from his work computer, then writes them to a removable media USB flash drive and transfers them to the KBR AWS, where they are encrypted and is signing. After that, the specialist transfers the protected electronic messages to the alienable medium, and then, via his work computer, writes them to the file server, from where they get to the UTA and then to the payment system of the Bank of Russia.

In this case, the channels for exchanging open and protected data will include: a file server, a specialist’s work computer, and alienable media.

Attack
The unauthorized attackers install a remote control system on a specialist’s work computer and, at the time of recording on an alienable carrier of payment orders (electronic messages) in open form, replace the contents of one of them. The specialist transfers the payment orders to the AWS of the CBD, signs and encrypts them, without noticing the substitution (for example, due to the large number of payment orders on the voyage, fatigue, etc.). After that, a fake payment order, passing through the technological chain, enters the payment system of the Bank of Russia.

Scenario 2. An example of the implementation of threats Y2.2 and Y4.2.

Description of the object


A computer with installed AWS of the CBD, SCAD Signature and the connected key carrier of the PCF vdToken functions in a dedicated room without access from the personnel.
The billing specialist is connected to the ARM CBD in the remote access mode via the RDP protocol.

Attack
The attackers intercept the details, using which the billing specialist connects and works with the AWS of the CBD (for example, at the expense of the malicious code on his computer). Then a connection is made on his behalf and a fake payment order is sent to the payment system of the Bank of Russia.

Scenario 3. An example of the realization of the threat

Description of the object


Consider one of the hypothetical options for the implementation of the ABS-KBR integration modules for the new scheme (AWS KBR-N), in which the electronic signature of outgoing documents takes place on the ABS side. In this case, we will assume that the ABS operates on the basis of an operating system that is not supported by SKZI SCAD Signature, and, accordingly, the cryptographic functionality has been moved to a separate virtual machine - the ABS-KBR integration module.
As a key carrier, a regular USB token is used, operating in a removable key mode. When connecting the key carrier to the hypervisor, it turned out that there are no free USB ports in the system, so it was decided to connect the USB token through a network USB hub, and install a USB-over-IP client to the virtual machine that will communicate with the hub.

Attack
The attackers intercepted the private key of the electronic signature from the communication channel between the USB hub and the hypervisor (the data was transmitted in clear text). Having the private key, the attackers formed a fake payment order, signed it with an electronic signature and sent it to the AWP KBR-N for execution.

Scenario 4. Example of the implementation of threats Y5.5.

Description of the object
Consider the same scheme as in the previous scenario. We assume that the emails coming from the AWS KBR-N fall into the \\ ... \ SHARE \ In folder, and those sent to the AWS KBR-N and further into the payment system of the Bank of Russia - into \\. .. \ SHARE \ out.
We will also assume that when implementing the integration module, the lists of revoked certificates are updated only when the cryptographic keys are reissued, and that the emails received in the \\ ... \ SHARE \ In folder are checked only for integrity control and trust control for the open key signature.

Attack

The attackers, using the keys stolen in the previous scenario, signed a fake payment order containing information about the receipt of money on the account of the fraudster client and inserted it into the secure data exchange channel. Since it is not the Bank of Russia that checks that the payment order is signed by the Bank of Russia, it is accepted for execution.