Threat Model

Owned by Former user (Deleted)
Last updated: Jan 06, 2011 by Michael VorburgerVersion comment

Introduction

This document is an outline of the attacker's goals and capabilities that we need to consider for Mifos security. The threats in this document can be used to develop the Mifos security recommendations document.

Scope

Threats to the following components of a typical Mifos deployment are considered:

  1. User (Loan Officer),
  2. Network,
  3. Web Server,
  4. Database.

The following threats are considered out of the scope of this document:

  1. Attacks involving physical access to a system hosting the Mifos software.
  2. Attacks on an underlying system hosting Mifos such as attacks on a virtual machine running a Mifos instance.
  3. Attacks on other systems using a Mifos database as a resource to build victims profiles.

Note0: A stretch goal could be to make it hard to attackers to use the data in the database.

Note1: Informative notes on the physical security of the system can be inserted.

Note2: There's not much we can do to prevent attacks on other systems by using the data on a Mifos database beyond telling people not to use the same username/password on Mifos that they have on other systems.

Scenarios

Typical usage scenario

The following steps outline in chronological order a new user (a Loan Officer) being added to the system and using it. These were extracted from the Mifos user manual

  1. A new loan officer (LO) is assigned to a particular center (sub division of a branch).
  2. An account is created at the Head Office, and login credentials are sent to the LO via email.
  3. (Optionally) Assigns a 'custom' role with permissions to perform certain other actions.
  4. The new LO logs in for the first time (and is required to change the first-use password before proceeding any further)

There is no additional setup steps and the Loan Officer can proceed to immediately add clients. The Loan Officer does the following:

  1. Create an account for a client
  2. Create or select a group (up to 30 people) for the new client
  3. Enters information about the new client
  4. Issues loans, which begins to track immediately
  5. Disburses the actual monetary loan

The typical administration setup scenario for new Loan Officer are as follows:

  1. Admin->new system user
  2. Assign the Loan Officer to a center

See chapter 3 of users guide for more details (comment: the user guide is outdated...)

Example deployment scenario

Physical outline: Two colocated machines

  1. One Web/Application server (Linux or Windows)
  2. One Database server (Linux or Windows)

Network access:

The web/application server allows incoming connections from the outside world on the following ports

  1. RDP (Windows) or SSH (Linux)
  2. HTTP
  3. HTTPS

The database server allows incoming connections from the outside world on the following ports:

  1. RDP (Windows) or SSH (Linux)

Additionally, the firewall allows incoming connections from the web/application server to the database server on the following ports:

  1. MySQL (3306)

Depending on the environment and OS used, additional ports may be opened between the web/application server in the DMZ and a server in the secure subnet such as DNS, NTP, etc.

The web/application server and the database server are on different subnets, typically with the web/application server in the DMZ and the database server in a secure subnet, behind a firewall allowing the connections above.

Note3: Mifos is not connected to any financial systems, it is only used to track transactions that were made in the real world. Thus, the attacker's incentive is now based on identity theft, competitive advantage and denial of service. A successful attacker would have enough information to deplete a client's bank account.

Note4: Recommend a method to minimize the threat of initial login credential compromise. E.g., if the initial credentials have to be sent via email, make Mifos automatically create a password that is intentionally hard to remember, thus giving the user an incentive to change the password. Recommend good password policy

Note4.5: ssh must use private/public key pairs. Password authentication and root log on must be disabled.

Note5: For additional scenarios, see the Mifos user manual

Threats

TODO This section needs some clean up

What property do we want to ensure, against what adversary?

  1. Transactions about loans, savings
  2. Personal identification of clients (borrowers)
  3. Data privacy for personal data and financial transaction trails for customers
  4. Proprietary and competitive information
  5. loan/savings totals
  6. repayment rates

Attackers

Who is the adversary?

  1. internal user (attempting fraud)
  2. recently fired loan officer (DoS)
  3. identity thieves (client's information)
  4. competitor businesses (loan information)

Attacker's Goals

  1. impersonation of clients (drain account, money laundering, payment of illegal activities)
  2. Malicious defacement or other damage to reputation
  3. Information leading to competitive advantages
  4. Identity theft
  5. Denial of Service

Attacks against a client

  1. Obtain an individual's loan information
  2. Obtain an individual's bank account information
  3. Obtain an individual's personal identity information

Attacks against a loan officer

  1. Obtain multiple clients loan information
  2. Obtain multiple clients bank account information
  3. Obtain multiple clients personal identity information

Attacks against a system

  1. Retrieve information existing accounts (See client and loan officer attacks above) to gain competitive advantage
  2. Deny service

Prioritized Threat Tables

User (Loan Officer) Based Threats

csv-table:: User Centric Threats:widths: 5 5 50 50
:header: Code, Priority, Threat, Mitigation

1-1, 1, Compromised Loan Officer login credentials (either by the LO or during transit from Head office), force password change upon first login. (see Mifos user manual chapter 1.3) 1-2, 3, Compromised client bank account information (depends on 1-1), 1-3, 2, Compromised client identity information (SSN; gov ID; address; phone; email) (depends on 1-1), 1-4, 4, Compromised client loan information (subset of 1-2?), 1-5, 8, Inaccessible system due to malicious activities, 1-6, 5, Scavenging of old data (leads to thread 1-1; 1-2 and 1-3), Secure deletion of old storage hardware (best practices) 1-7, 7, Activity analysis, 1-8, 6, Loss of equipment containing private information. (e.g. laptop stolen with password saved in browser), good password policies. (e.g. first letter in random phrase. Don't save password in browser.) 1-9, N/A, Loss of equipment containing private information. (e.g. laptop stolen with password saved in browser), Same as 1-8

Database and Application Centric Threats

csv-table:: Database and Application Centric Threats:widths: 5 5 50 50
:header: Code, Priority, Threat, Mitigation

2-1, 1, compromise of backup user, Perform backups from a secure box using only secured communication channels. 2-2, 2, Compromise of backup user's private key, 2-3, 3, SQL injection, Sanitize inputs 2-4, 4, Access to execute arbitrary code (from limited account and root), Ensure system is fully patched (good patching policies). Open only ports that are absolutely necessary and time limiting them as needed. 2-5, 5, Access to read data. (remote) Any malicious user with access inside the firewall and credentials to the database. (local) Theft of physical hardware hosting the database., 2-6, 6, Access to write (tamper) data. (Same as 2-5) 2-7, 7, Access to destroy data (subset of 2-6), regular offline backups 2-8, 8, Compromise of data flowing between the web server and the database. Requires that the attacker has access to at least the DMZ network, protect data between web server and db. TLS tunnel? 2-9, 9, Compromise of backup data, 2-10, 10, Configuration error, best practices document

Web Server Centric Threats

csv-table:: Web Server Centric Threats:widths: 5 5 50 50
:header: Code, Priority, Threat, Mitigation

3-1, 1, Access to replace valid software with malicious one, 3-2, , (subset of 3-1) Access to execute resident code (from limited account and root), 3-3, ,(repeat of 3-2) Access to execute arbitrary code (from limited account and root), 3-4, 2, compromised Operating System, good patching policy. 3-5, 3, Access to read data (secret configuration; e.g. SQL creds), 3-6, , (same as 3-6) compromise of Mifos software, Good backup policy 3-7, 4, Exploitation of side vectors to get to Mifos data. In a central hosted cloud Mifos would probably run in a virtual machine. A malicious process with access to another virtual machine on the same physical machine could do some damage depending on strong the checks on the hypervisor are. Another side vector is Tomcat. A vulnerability in that software could lead to a compromise of Mifos data to no fault of Mifos., Secure policy on virtualized components. Strip down all unnecessary software (recommend baseline like PCS) semi-automatic software update mechanism. (Tough. Need to avoid loss of service due to patching on very heterogeneous networks.)

3-8, 5, Software error (bug), 3-9, 6, Configuration error. (Leaving default tomcat page...etc), 3-10, 7, Unauthorized remote access to server. Typically through compromised credentials of maintenance and support staff., web server account set to a limited one with privs only to complete tasks needed. 3-11, ,(repeat of 3-10) Compromise of administrative credential (e.g. administrator; software update; remote administrator), 3-12, 8, Scavenging of old server (physical machine), 3-13, 9, Physical theft of server or parts thereof., 3-14, 10, Loss or compromise of Logs, remote storage of critical logging information. Note: sanitize log info. print user ID and not what the user typed.

Network Centric Threats

csv-table:: Network Centric Threats:widths: 5 5 50 50
:header: Code, Priority, Threat, Mitigation

4-1, 1, Eavesdropping of information, use TLS 4-2, , (subset of 4-1) Modification (tampering) of information, 4-3, , (subset of 4-1) Replay of information, 4-4, 2, Man in the Middle during legitimate communication, appropriate warning messages. CAcert and don't ignore warning. Bullet proof docs for installation and maintenance of certs to minimize (or eliminate warning messages) 4-5, 4, compromise of credentials for remote maintenance, 4-6, 8, Corruption of time information to falsify timestamps, Authenticated NTP with NIST. http://tf.nist.gov/service/auth_ntp.htm 4-7, 9, Exploitation of side vectors (other running programs) to get to Mifos data., Firewall with only port 80 (if necessary) and 443 open. Put Web server in DMZ. 4-8, 10, Denial of service, 4-9, , (subset of 4-8) Flooding of requests TODO define requests, 4-10, , (subset of 3-8) Vector for remote exploitation. (Software bug),

Open Questions

  1. Is there enough information in Mifos for an attacker to deplete a client's bank account?
  2. What is a typical deployment scenario?
  3. What is a typical use case?
  4. Can we divide deployment into security categories (low, medium, high) to customize security requirements?
  5. RDP ports open to the outside world? VPN then RDP? logs?
  6. What is the motivation of an attacker

Glossary

  • Activity analysis: The fact that a pipe (even secured) was established leaks information. Moreover, the frequency and timing of packets sent over that pipe leaks information as well.
  • Man in the Middle (MIM, MITM): An attacker sitting between the client and the server, pretending to be the client to the server and pretending to be the server to the client while being able to see and tamper with any information between the legitimate client and server.

References and tools ====