Security Analysis of Access Control Management System

Gregory Mason, Nikolay Nikiforov, Rupert To, and Kevin White

Abstract
This paper is an analysis of the Access Control Management System used in the Kaiser, McLeod, ICICS-CS, Dempster, and Brimacombe buildings.  The paper first introduces the system and how it runs.  Next the approach taken to attack the problem is outlined.  The weaknesses of the system are then presented, followed by some possible solutions.

1. Introduction

With student enrolment increasing yearly, it has become more and more difficult to manage access to the various buildings around campus.  Upon the completion of the new Fred Kaiser Building, the department of Computer and Electrical Engineering in partnership with the department of Computer Science has begun using the FOB key system for building access.  This system was put into place to create a universal access system, which eliminated the need for multiple keys, and was also able to manage the large number of students, faculty and staff members involved.  In order to run such a large scale system with thousands of users, the Access Control Management System (ACMS) was created.  This paper will analyse the ACMS used to regulate the system, looking at the possible security flaws, as well as proposing solutions to fix them. The system’s weaknesses and vulnerabilities have been separated in two groups; administrative and technical.

2. ACMS

The ACMS is the software which controls the access control to the McLeod, Kaiser, ICICS-CS, and Brimacombe buildings.  The ACMS was designed with two goals in mind, one, it should delegate responsibility of granting and denying access, and two, it needed to effectively manage 3000+ users of buildings [4].  There are five levels that run the system from a design prospective, as well as five levels of administrative privileges.

2.1 System design 

In order to enter the building the user is required to swipe a FOB key by a small FOB reading mechanism located next to every door. If the user has the appropriate rights to gain access through this door, the door will open. This process is governed through five levels of control. The five levels that make up the system design are the Access Controlled doors (ACDs), Zones, Roles, Users, and FOBs.  The relationship between the levels forms the intricate structure that is the ACMS.
The ACDs are the various doors throughout the buildings that are equipped with card readers and electrified door equipment.  The ownership of the ACDs is the building they belong to. ACDs give access to one or more zones.  Currently the ACDs are running on 3rd party equipment with proprietary rights, thus the system administrator does not have the ability to know if anything within the equipment has gone wrong. 
Zones are the logical representation of areas in a building that are accessible via one or more ACDs.  Zones are owned by orginazational units, such as EECE or Computer Science, and access is only given to a zone by its corresponding orginazation.  Zones can be accessed through one or more ACD, and are associated to one or more roles.
Roles are logical representations of a user’s relationship with an organizational unit.  Roles are also owned by an organizational unit,   roles grant access to one or more zones, and are assigned with users.
Users are the everyday people that require access to the building and its facilities, such as students, faculty members, or building staff.  Users are owned by the system, they can be assigned to one or more roles, and have one FOB issued to them.
FOBs are the access control tokens issued to users; they come in two forms either a card or a fob.  FOBs have two states of ownership, zero, which means they have not been issued or they have been lost, or user, which mean they have been issued to one person. A FOB serves as an identity card, it holds the users identification and the ACD knows whether this identity has been assigned the right role to access the zone associated with this ACD. [5]

2.2 Administrative management

There are five levels of administrative management, clerk, restricted admin, admin, department admin, and super admin.  The administrative rights work on an inheritance system, where each level inherits the abilities of the level below it as well as additional control over the ACMS.
The clerk is the lowest level, and thus inherits nothing.  Clerks have the ability to activate or deactivate FOBs, as well as basic user to role assignment. They also have the ability to declare a FOB as lost, stolen or to simply change the expiry date, causing it automatically deactivate.
A restricted admin would be a faculty member or TA, who would be able to grant access to one set of roles to a user, such as to give access to a lab or research area.
An admin inherits the abilities of a clerk and a restricted admin.  It is also able to create roles, users, or zones.  An administrator is specific to a department, i.e. computer science or EECE.
A department has all the privileges of an administrator, but it is able to create ACDs.
A super admin is the top level and thus inherits all the abilities of the four lower levels.   It has the ability to act across all departments.

2.3 Storing data

EECE and Computer Science each have there own server to which they store data on.  These servers are updated four times a day from the remote clients.  Thus when a change is made to the ACMS it is not active right away.  The remote clients are web-based and written in Java.  The client connects to the server via HTTPS, with cross site scripting of cookies.  The ACMS generates an encrypted dump file, which contains FOB numbers, and is loaded onto the third party hardware.

3 Flow of events 

The scope of this project changed throughout the term, initially we had planned to do a analyse project.  We found it difficult to obtain information in order for us to analyse it properly.  At this point, we then looked at doing a design project, but upon further investigation we found the design of the system to be fairly sound.  After meeting with the designer of the system we found the information he gave us sufficient to do an analysis project.

3.1 The initial approach 

Initially the team began to look at the analysis from a very technical perspective. It was decided to acquire the source code for the system from the person who implemented the solution and to analyze it in detail. The analysis could have provided ideas and revealed hidden weaknesses throughout the system. Once analysed the discovered problems could have been solved. Unfortunately, we were denied access to the code. One possible reason for that would be that the security of the system depends on the secrecy of the source code. This would be a major violation of the basic procedures associated with designing secure systems.  Either way we were unable to do anything about that and so we moved to our second approach.

3.2 The second approach 

The team’s second approach to the analysis was to target the access control model itself. After a little bit of research and a personal interview with one of the clerks currently operating the system, Jake Jacobs, we figured that the system operated on a Role Based Access Control model, otherwise known as RBAC. 
As computer systems evolved to feature multiple applications and serve multiple users, a heightened awareness for data security has emerged. System designers have begun developing access control models. Some early models include a mandatory access control (MAC) and a discretionary access control (DAC). A newer and alternative approach is the role-based access control (RBAC).	
The DAC model allows individual users to define an access control mechanism allowing or denying access to an object. This model relies on the identity of the subject and object involved. Unlike the DAC, in the MAC model the system mechanism controls access to an object and an individual user cannot change that (Bishop, 53). The RBAC model is a superior model to both the DAC and the MAC models, because in this model roles are created for various job functions, permissions are assigned to those roles and users are assigned a particular role. Through those roles the user has permission to perform the particular system functions [3]. 
The RBAC model presents various reasons, as to why it is the better model to be used by the Access Control Management System (ACMS) managing the access to the Computer and Electrical Engineering and the Computer Science buildings. The model has the capability to establish relation between various roles, between permissions and roles and between users and roles. For example two roles can be mutually exclusive not allowing a user to establish both roles at the same time. Roles can also be inherited, so that a user with a higher security clearance role automatically inherits roles with lower security clearance. Other important qualities include separation of duty (static and dynamic) and delegation of authority. Probably, the most important thing is that permissions assigned to roles tend to change relatively slowly, compared to users in the system and it requires a lot less technical skills to assign or remove users from specific roles than to change the permissions. The RBAC system allows for an automatic permission assignment to various users, based on what access they require [3]. 	
As we researched the RBAC model, the team came to an agreement that the goals of the current ACMS are sufficiently satisfied with the RBAC model and any improvements that we can come up with would be insignificant. Based on this we decided to move back to a more technical analysis but this time we focused more on the design of the system rather than the implementation of the system.
3.3 The final approach 

The team scheduled an interview with the designer of the ACMS, Luca Filipozzi. Luca presented many strengths as well as weaknesses of the ACMS. We were able to group the weaknesses into two major categories, administrative and technical.

4. Administrative weaknesses

As with any system requiring human interaction, there is an element of weakness tied to the user. With respect to the ACMS there are a few key areas that can be identified as weak points to the sound operation of the system: malicious administration, a large administration population and miscommunication or user mistake. These areas concern the social engineering aspect of system design and are often overlooked or discounted during the design and implementation of a system.

4.1 Malicious administration

An untrustworthy administrator within the system is a prominent weakness of the ACMS. An administrative user could perform the following actions:
•	Set a user’s status to “inactive”
•	Declare a user’s FOB as lost
•	Set a user’s expiration date within the system to an earlier date
These actions would result in the user being locked out globally. They would thus not be able to enter any buildings or rooms they had been previously granted access to.
A malicious administrative user could also grant access to an unauthorized individual. This means that a person not authorized to enter a certain room or building could have access when they are not supposed to. They could also prolong a user’s activity within the system by extending their expiration date. This would mean a user could have access to a room or building when they are not supposed to. For example, a user with an expected access time to terminate in December 2005 could have their access prolonged to December 2006. This could result in unauthorized activity or theft to occur within certain areas.
A malicious administrative user is a major point of weakness as it is difficult to predict a human’s behaviour. A method to assist in reducing the probability of a malicious administrative user entering the population is to maintain a low administrative user population.

4.2 Large administration population

As a population grows, the scope of people represented by that populace increases as well. As an administration population grows, the probability of a malicious user entering the system increases as well. By maintaining a low administration population, the chance of malicious behaviour occurring can be reduced. Currently, the administration population currently sits at approximately 20-30 people. As the ACMS becomes more apparent throughout the campus, the administrative population must grow to accommodate the increased number of user activity within the system. Implementing a strict authorization process with any activity concerning the user database is a vital point of interest. Ensuring that an authorization hierarchy be implemented and followed would also help in reducing any malicious activity taking place. 

4.3 Miscommunication or user mistake

An inevitable point of weakness that comes with human interaction with a system is human error. The error can lie with either the user or the administrator. If a user does not properly communicate which rooms they require access to, they could be assigned access to an incorrect room. An administrator could mistakenly select the incorrect role from the menu. An administrator could also mistake one role for another and assign the wrong one to a user. These two scenarios would leave the user locked out of the room they expected access to. Another error is an administrator could possibly assign access to a room or lab but not to the building. This would leave the user stranded outside the building if they were to attempt to access a building outside of normal operation hours.

5.0 Technical weaknesses

In addition to administrative weaknesses concerning the human user, there are also several technical weaknesses tied to the system itself. Issues such as third party software and proprietary rights have great effect on the technical weaknesses of the system. The manner in which the system is accessed is a major weak point as well, leaving the system vulnerable to a plethora of attacks.

5.1 Web based client

Perhaps the most prominent weakness of the system is the manner in which it is accessed by an administrative user. The client that an administrative user uses to access the system is web-based. This means that all transmissions of information are done over an internet connection. In today’s world, the internet is a volatile environment in which to transmit information.
There are several safeguards to protect against unauthorized access to the system. 
•	Encrypted communication
o	The information being transmitted over the network is done in the HTTPS protocol. 
o	The session data is encrypted using SSL as well.
•	User authentication
o	An administrative user must verify their identity via username and password.
•	Trusted host
o	The connection to the system must be done via a trusted host within the department. An attacker must physically be at a trusted host within the department to administer any dictionary or brute force attacks on the username and password.
There are many threats to a system such as the one being analyzed in this report. The added component of a web-based client increases the level of threats. Some threats include but are not restricted to the following:
•	IP spoofing
o	An attacker can modify the IP header of a packet. Changing the source IP address field to that of one within the trusted network of the system.
•	Session hi-jacking
o	If a trusted host were to become compromised somehow, an attacker could retrieve a session cookie to skip the authentication process.
•	Host impersonating
o	Similar to session hi-jacking, if a trusted host were to become compromised, an attacker could set up a proxy on the host and impersonate himself/herself as the trusted host.
•	Man-in-the-Middle attack
o	Attempting such an attack as this would still require the attacker to physically be at a trusted host. If access to a trusted host could be attained, an attack such as this could occur.

5.2 Dump file

Within the system there is a large dump file containing all the users and their associated roles. Thus, this file holds the all information that enables users to access rooms and buildings. 
This dump file is generated by the ACMS server and is transmitted to the master panels (as well as the slave panels) of each building several times a day. The dump file is transmitted with encryption techniques. Although the dump file is transmitted in an encrypted manner, the network itself is still considered insecure. Thus, a weak point resides in the fact that an attacker can intercept this file and augment its information maliciously. An attacker could then add or delete roles at will, granting access to whomever and for any period of time they wish. This augmentation would also be very difficult to detect. 

5.3 Miscellaneous 

Some miscellaneous weaknesses are mentioned below. ACMS server runs on Windows NT. This operating system is susceptible to crashing and has many security vulnerabilities.
All transactions and connections within the ACMS server are logged in an ORACLE database. If an attacker can obtain a username and password, they could login to the database, alter the logs and thus render the auditing system useless. An attacker could freely perform any actions within the system and simply cover their tracks by altering the auditing logs.

5.4 Ettercap

One program the system is specifically weak to is Ettercap.  It is an open source program, described by its authors as “a multipurpose sniffer/interceptor/logger for switched LANs [7].”  It supports active and passive dissection of many protocols, even ciphered ones. 
Specific dangers to the ACMS would be that is can sniff HTTPS, passive LAN scanning, can perform man in the middle attacks, packet filtering or dropping, or a denial of service attack with the ability to kill the connection.
This program could give a malicious user the ability to lock out the system, thus causing all the doors to remain locked.  He could also intercept data, and could then either give himself full access, or deny someone access.

6. Solutions

This section will present some possible solutions to the problems prevent in the previous sections.

6.1 Malicious administration

The best way to prevent malicious administration is to implement an auditing system.  Comprised on a logger, analyzer and notifier, this is the simplest and most effective way to prevent this problem.
The logging mechanism records all the events that occur in one day.  Thus would most likely by done in human readable form, but could also be in binary.  Thus if an unwanted change were to occur you could pin point when it had occurred, and by who.
The analyzing system takes the log input, and evaluates it.  It would search for possible abnormalities, such as a user access had been turned off, or a user had been giving unlimited access.  It would also look for if a FOB had expired.
The notifier could then alert the system admin if any of the results of the audit were need for concern.  This would allow for any unwanted changes to be undone, and could lead to the discipline of the person(s) responsible, whether accidentally or on purpose.

6.2 Web based client

This is one aspect of the design that opens it up to the most possibilities for attack, but due to the needs of the system little can be done to eliminate this problem.
Since one of the goals of the ACMS is delegate responsibility, have a single terminal connected directly to the server is an infeasible possibility.
One recommendation given by the system designer would be to require SSL certificates when authenticating, thus giving an increased level of security.

6.3 Dump file

This is one area of the system that leaves it open to attacks due to the hardware used.  Due to proprietary rights, this file can not be verified once it is uploaded onto the panels.  Thus if a malicious user uploaded a corrupt file, there would be no way of knowing this.  In order for this problem to be eliminated the hardware would need to be replaced with that which was not proprietary.

6.4 Ettercap

This is one area of the system that can be difficult to defend against, but there are steps that can be taken to stop this, or similar kinds of attack.
The first is education of the administration staff.  By training then not to accept suspicious certificates, and alert the head admin of any suspicious activity is one step in preventing attacks.
The next line of defence would be to install some form of defence tools to monitor the network for changes in the APR data.  This can be done by programs such as arpwatch, or ettercap itself is even able to monitor for any APR poisoners.
Another prevention method is to have port security with configured switches.  By having a strict limit on MAC addresses to certain switches, you can prevent unauthorized systems from accessing the LAN.
One last prevention method would be to have a Static APR table.  This would contain a list of valid IP to MAC address mappings.  Unfortunately this table is not dynamic and would need to be updated regularly.  Though it would prevent classic APR poisoning.

7. Conclusion

After a through security analysis we found the system to be fairly secure, but there were some areas that could be improved to prevent any malicious activity.  By adding an auditing system, requiring SSL certificates, and adding some defence tools, the current system would become very secure.

References

[1] Aharoni, Mati. EtterCap - ARP Spoofing And Beyond. 23 Jun 2003. http://securitypronews.com/securitypronews-24-20030623EtterCapARP SpoofingandBeyond.html 11 Nov. 2005.

[2] Bishop, Matt, Introduction to Computer Security ,Addison Wesley Professional. 2005.

[3] Coyne, Edward J., Feinstein, Hal L., Youman, Charles E., Sandhu, Ravi S. Role-Based Access Control Models, George Mason University.

[4] Filipozzi, Luca. Personal Interview. 22 Nov. 2005.

[5] Information Technology Support Office. How to Gain Physical Access. 10 Oct. 2005. University of British Columbia  11 Nov. 2005.

[6] Jacobs, Jake. Personal Interview.  Oct. 2005.

[7] Norton, Duane. An Ettercap Primer. GIAC Security Essential Certification. 14 April, 2004.

[8] Sourceforge.net. Ettercap NG. http://ettercap.sourceforge.net/ 11 Nov. 2005.