EC56401: Computer Security October 25, 2024

Project Description: AlphaBank Engine

Instructor: Santiago Torres-Arias

1 Project Information and Goals

This is the only project on the course, and it focuses on developing outcomes: 2) “Design a Secure System”,
and 4) “Analyze a Given system and determine the appropriate security mechanisms for it.”
In order to achieve these outcomes, you will be implementing a relatively complex system on Phase I as a
team, and then trade your implementation with another team in the course to identify and propose security
fixes on Phase II. More details on the timelines for each phase will be provided below.

1.1 System Overview

As part of your new software engineer jobs, you managed to acquire a contract with the infamous AlphaBank
of previous homeworks. AlphaBank is going digital in 2024! As part of their digital strategy, they have
decided to add an interactive console for payment processing (much like Venmo and PayPal have). Though
the user interface is being worked on in-house, they have decided to award a contract to a company with
more security experience. That is you.

1.2 Team Formation

Please form a team of 3 people of your choosing. No exceptions, as it wouldn’t be fair to your other
classmates. If you do not have a team, please use the forum for this assignment, or reach out to me.

1.3 Deliverables & Formatting

Each team will submit four deliverables. Two deliverables satisfy the Phase I of the course, and two
deliverables will Satisfy the Phase II of the course. While I will send a clarifying document for Phase II, I’ll
still outline the generalities of the deliverables involved here.

• Phase I:
Software Artifact This includes the implementation of the AlphaBank engine, as well as supporting
files for its deployment and functionality.
Requirements Analysis An accompanying document outlining the architecture of the software, as
well as the mechanisms you implemented to achieve the security goals.
• Phase II:
Attack Software Any scripts used to carry out the attack, as well as their description (in code)
Final Presentation A presentation outlining your methodology and findings when attacking another
team’s Software Artifact.

More specifics about the Software Artifact and Requirements Analysis will be provided in Section 3.

1
2 Phase I: Project Requirements
This section outlines the requirements for how you are intended to implement this software components. I’m
describing the project as a contract would, which usually outlines requirements, and specifications for the
requirements. Your ability to satisfy these requirements is part of the grade of your Phase I deliverable.

2.1 Contextual Requirements

A contextual requirement does not define the behavior of an application per-se. Instead, it sets some
requirements that are specific to the context of where an application is supposed to run. For example, a
common contextual requirement is: “the application needs to be written in language X, because the rest of
the software stack is also in language X”
Below, I outline some contextual requirements of the application, as well as the reasoning why. Keep in
mind, you need to justify how you met these requirements.

Requirement C.0 Name: Single-Call binary

The application needs to run as a single-call binary (i.e., no sub-commands). It is possible to use an
interpreter, e.g., such as python

With the above requirement in mind, consider that you can use whatever language of your choice. How-
ever, its necessary for you to allow your peers to build their software. When in doubt, ask whether you can
bundle a compiler or how to better make a software easy to build for your peers.

Requirement C.1 Name: Containerized Application

The application needs to be containerized. This means, you should use a Dockerfile or Podfile or
whichever to bootstrap your application

In order to simplify sharing the code, I ask of you that you bundle your application inside of a container.
I recommend using docker or podman, but I really don’t care as long as it is OCI [2] compliant.
Lastly, we will require network connectivity

Requirement C.2 Name: Network Connectivity

The application needs to listen on TCP port 6201. This port is arbitrarily chosen

Most programming languages have native socket support.

2.2 Functional Requirements

Moving on with the functional requirements. These describe how the application is supposed to behave, and
to achieve.

2.2.1 Interface Definition

First off, we define the interface in which the system is to interact with users. Given that it’s a networked
application, you must support users to connect to the TCP stream and submit line commands in text form.

Requirement F.3 Name: Line-based command interface

The engine must support arbitrary commands from a connected user. These commands will also take
an arbitrary number of parameters. Communication should be done at line end, and not streaming
byte-by-byte. This is often found as line-mode — as opposed to character mode — in terminals and
protocools

2
 For example, see the listing below:

AlphaBank> LOGIN Santiago AlphaC00l!

This would allow me to log into your system using my username Santiago and the password AlphaC00l!.
This interface is strictly plaintext! Using any cutesy/fancy HTTP engines, or SSH, or Protobuf, or XMLRPC
is prohibited.
Speaking of which, in addition to command support, We must also provide feedback to the user via a
prompt. The example above showed us an AlphaBank> prompt to let the user know they were using the
AlphaBank online system.

Requirement F.4 Name: Interactive Prompt Feedback

A prompt should show information about the state of the system to the user.

The only two things to provide to the user on the prompt is the AlphaBank> banner, as well as the
currently logged in user, and the role1 . See for example this banner showing a logged in user acting as an
administrator role:

AlphaBank(Santiago:ADMIN)>

Another important apect of the system is that of concurrent users.

Requirement F.5 Name: Concurrent Connections

The system should allow for more than 3, and up to 16 different users, tellers, and admins (total)
carrying out commands simultaneously

This is very low for any self-respecting bank, but I believe that supporting 16 users max is “fair” for this
contract.

2.2.2 Users and Roles

The system supports users (identified by login), and their roles.
A role describes the capabilities of a user, and there are only three of them:

Users I.e., clients of AlphaBank. They will send and request money
Tellers I.e., employees of alphabank. They can enroll users, deposit and withdraw money
Admins i.e., the head honcho. They can do whatever they want

Requirement F.6 Name: Support for Roles

The AlphaBank system can support users and roles and these are assigned by an Administrator.
Roles limit the commands that each user can carry out in the system.

In other words, the roles limit which commands each user can make. By default, the AlphaBank engine
comes with a default user that can be used to bootstrap the system.

Requirement F.7 Name: Default Admin User

The application comes in with an encoded default admin user admin with the password Spookytus

All users, including the admin, has an assigned list of funds, which are deposited by tellers upon confir-
mation in person (we will handwave this in practice). Funds increase in one of the following three conditions:
1 more on this below

3
Deposit A teller is presented with cash, which is deposited and the corresponding funds are assigned to the
right account
Withdraw A client requests their money back, and the amount is substracted from the right account
Transfer Two clients request a money transfer. Funds from one acount are moved into another account.

2.2.3 Supported Commands

The interface described above allows for a collection of commands. Below is a list of commands, the param-
eters that they take, and the behavior expected.
• User Commands
login (Username, Password) → SUCCESS/FAIL: initiate a session in alphabank
send (Username, Amount) → TXID/FAIL: Create a send transaction for target user
request (Username, Amount) → TXID/FAIL: Create a send transaction for target user
approve (TXID) → SUCCESS/FAIL: Approve a pending transaction identified by TXID
• Teller Commands
deposit (Username, Amount) → TXID/FAIL: Deposit funds from cash to username
withdraw (Username, Amount) → TXID/FAIL: Withdraw cash from account of username
enroll (Username, Password) → SUCCESS/FAIL: Create a new account
• Admin Commands
promote (Username) → SUCCESS/FAIL: Upgrade user to teller, or teller to admin
demote (Username) → SUCCESS/FAIL: Demote admin to teller, or teller to user
The commands above are all available to a user with the indicated role, or above. For example, a user
annot deposit, but a teller can deposit as well as send and approve.
SUCCESS/FAIL indicates whether a command should silently carry out the action, or indicate an error
ocurred (with a clear error message) and fall back to the prompt. TXID is a number indicating that a
pending transaction has been scheduled and is waiting for approval (i.e., the right user must call approve on
it).

Requirement F.8 Name: Command Support

The Engine supports all the commands listed above

2.2.4 Persistence
Besides the features described above, the system must support persistence. This is, if the application is
restarted, the users, passwords, roles and funds must be recoverable. A database or any storage backend
should allow for this.
Since we are using docker, you are welcome to use either a second container (e.g., with a database), or a
volume, or plainly saving the file (which would mean we need to restart the container instance rather than
re-launch each. All of these are valid.

2.2.5 Demo Client

In order to prove that the application work, you should submit a supporting script/application that can
connect to a running instance. This can be as simple as netcat [1] or openssl s client. Any cryptographic
certificates, secrets, etc that are needed to connect need to be provided to the attacking team. Lastly, the
application should only provide an interactive prompt (i.e., no commands should be wrapper, I want to type
them myself).

4
2.3 Security Requirements
The above describes the requirements in terms of functionality. We also need to ensure the safety of Alpha-
Bank’s customers and, thus, we must set forth some security requirements as well.

2.3.1 Confidentiality
Password confidentiality is perhaps the most important of them all.

Requirement S.9 Name: Password Confidentiality

Confidentiality of password information must be provided even in the case of database breach

Similarly, account information across users shouldn’t be provided.

Requirement S.10 Name: Funds Confidentiality

Any logged in user can’t obtain visibility over the funds of any other user.

Lastly, the mere knowledge that a user holds an account in our bank can put them at risk.

Requirement S.11 Name: Account Confidentiality

It is impossible for a logged in user to know the existence of another user without providing the
username of such user

Note that the first requirement assumes an attacker stole the database. The second and third one does
not necessarily do so.

2.3.2 Integrity
Besides confidentiality, we must also ensure the integrity of the system. Perhaps the most important aspect
in this regard is funds integrity.

Requirement S.12 Name: Funds Integrity

This is akin to law 0 of thermodynamics: no funds shall be created or destroyed (unless they are
deposited or withdrawn). This also includes known bugs in banking software such as double-spend.
Funds shall never be allowed to go under 0

In addition, we want to make sure that the integrity of user information cannot be maliciously modified.

Requirement S.13 Name: Account Integrity

Usernames and Passwords cannot be modified by an attacker — not even an admin!

Another requirement applies to roles

Requirement S.14 Name: Role Protection

Nobody but a logged in administrator can promote and/or demote users

Lastly, one for transactions:

5
 Requirement S.15 Name: Transaction Integrity

No user can bypass transaction approval

2.3.3 Availability
There is only one availability requirement:

Requirement S.16 Name: System Availability

The system should not crash with a malicious user or teller input

That is, we must ensure that a malicious user is not able to crash the bank for everybody.

2.4 Attack Scenarios

I will elaborate more on this later, but namely. Assume four types of attackers:

Malicious Insider: A malicious insider does not have access to the system, but is able to obtain a copy
of the database and analyze it to carry out malicious tasks. This copy of the database is not loaded back
into the system, so no modifications of the database should affect the behavior of the running system.
An attacker of this nature can choose whenever to “pause” the application (i.e., shut it down) to study
the database. Once done analyzing, they can bring it back up and attack the application.

Person-in-the-middle: A person-in-the-middle is an attacker able to interpose between the client and

engine communications to, for example, tamper with commands and read sensitive information as it is going
through the network. This attacker is not able to tamper certificates or private keys from the engine, but
can provide malicious keys to the client, unless such client has a suitable root of trust.

Malicious Client: A malicious client will send crafted input to the application to achieve malicious results.
These include, but are not limited to: 1) stealing funds from another user or 2) Becoming a user with higher
privilege.

Malicious Teller: A malicious teller will send crafted input to the application to achieve malicious results.
These include, but are not limited to: 1) carry out unauthorized transactions, or 2) Becoming a user with
higher privilege.

3 Deliverable & General Rules

Below are some guidelines for the deliverable and other rules.

3.1 Software Artifact

The software artifact must be self contained. An .tar.gz or .zip archive is a suitable method to transfer
all the archive contents.

Info
If you’re using git: git-archive is a useful subcommand to do this!

This archive should contain at least:

• The sourcecode

6
 • A Dockerfile to build such sourcecode
• A README.md file describing the steps needed to build and test. Please include teammate information
here for simplicity
• A client.sh script to connect to the built binary

• Anything else that you think will help us run your application

3.2 Requirements Analysis

Besides the software artifact, I also require a requirements analysis.
This is not much different from a writeup for a homework, for example. In, it, please include the following
sections:

• An exploration of the requirements and your interpretation

• A description of the software architecture (e.g, modules, files, algorithms, etc)
• An elaboration of how each requirement (using their codes) are satisfied

References
[1] Netcat 1.10. https://nc110.sourceforge.io/.
[2] Open container initiative. https://opencontainers.org/.