Server vznikl za podpory Grantové agentury ČR.
Behavioural approach to operation of access control systems and its vulnerabilitiesVydáno dne 15. 05. 2015 (2650 přečtení)
The goal of this article is to describe behavioural operation of access control systems and to point out some workarounds for some exploitation.
The goal of access control systems is to limit an access from free to controlled, and to restrict access for unauthorized users. They can be met on daily basis, while man can often be a participant as well. Human societies are organized, hierarchical and with expected behaviour because of controlling the access. This paper deals exclusively with access which is controlled. This is a case in which not every Supplicant is automatically allowed to access the asset, but only those, who are authorized for that type of access. A description of such behavioural system is elaborated throughout the paper. This includes a description of system's environment, user roles, bounds between statuses of user's role and system internal processes. In second part, three examples of attack methods to access control system, which may lead to unauthorized access to asset, are described, illustrated and evaluated.
Keywords: access control; authentication; authorization; accounting; registration
Controlling the access is quite an old natural phenomenon, old as mankind itself. It deals with protection of wide range of assets, such as valuables, value object, knowledge, information, activity, position in society or organization, human life, etc.
Asset is something whose characteristics lead to be useful and rare, and needs to be protected against misuse and undesirable effects. This protection is provided by access control system.
On the other hand, there is another sort of systems, which does not restrict or control the access and therefore does not do the controlling of the access. This type of systems are not dealt with in this paper.Access Control System
This sort of system is a form of formalized, organized constellation of elements with their relations between each other, which communicates with its surroundings and behave due its expected strictly defined behaviour. Access control system (or the System) is set of security tools, methods, procedures, legal-administrative measures, directives, notices, regulations and contracts. Access control systems are supported with legislative framework, which permits their usage within its scope (e.g. property law, right to property).
In terms of access control, Entity can be a person, group, organization, computer's running process, etc.
In its basic form, access control system is used by these External_entities:
Authority - is an Entity which is an owner of the asset and wants to control/restrict its access. Hence access control system is chosen, installed, set and operated by the Authority, therefore its desired condition for securing the asset is achieved.
Supplicant - is an Entity which wants to access to the asset. For doing so, he enters the access control system and uses its procedures and processes to gain the access to desired asset.
Fig. 1: Access control system with its external Entities
As this concept of abstraction of Entity and Identity solely exist and residue inside the System, they are marked with adjective "Virtual".
Basic operation of the System consists of the following activities and tasks:
Further sections are using the following terminology:
Fig. 2: Databases used inside the System
ACTIVITY: CREATING ABILITY TO ACCESS THE ASSET:setting up the System
Fig. 3: Procedure for creating ability to access the asset
There is an entity of Supplicant, who has the role of Applicant.
(default status): In the beginning, Applicant (represented by Entity of Supplicant) is in a state of External_applicant, who wants to have an allowed access to the specific asset.
After the process of Registration, an image of Applicant (Virtual_entity) is saved into the System which transforms External_applicant to Registered_user.
After the process of Authorization, authorization record is saved in the System, thereafter which Registered_user becomes Asset_user.
These processes are further described in the following sections in behavioural manner:
Purpose of Registration is to create an object (Virtual_entity) inside the System, which will represent its (usually real) original model (owner) in an authentic way (which in this case means Entity of Supplicant). A user account in the System is created for the Applicant (entity of Supplicant), who has agreed to abide with terms of agreement set by Authority. It is some form of Virtual_entity which is written down in e.g. a list on page of paper, filling cabinet, computer database, etc. Subsequently, this Virtual_entity represents External_entity in the System which means that everything that is made by Virtual_entity is referring to its owner (Supplicant in this particular case). That is due bound between External_entity and Virtual_entity, which is in this case 1:1 (one-to-one).
The Registration per se is a process after which External_applicant becomes Registered_user. This process is basically conditioned by several procedures. During these procedures, several steps are made such as creation of new Virtual_entity inside the System, creation of a new Virtual_identity from registration form, assignment of Virtual_identity to the Virtual_entity, establishment of a method for claiming Virtual_identity (authentication method), approvement of terms of the contract.
After the Registration process, there is a new entry in Database_of_registered_users which contains newly created Virtual_entity of registered user. This entry operates as Virtual_entity which represents Entity of Applicant inside the System. This newly created Virtual_entity contains a set of attributes from registration form used in process of Registration, its Virtual_identity (user identification number, name, address, e-mail contact, login, password, etc.).
Purpose of Authorization is to create traceable entry in form of ordered pair (U_i ; A_j), where:
The Authorization itself is a process after which Registered_user becomes Asset_user. This process is basically conditioned by several requirements specified by Authority, which Registered_user undertakes responsibility to abide. Authorization entry is confirmed by Authority. It is a crucial step for ability to get granted access to the asset.
After the Authorization process, there is a new entry in Database_of_authorizations containing Registered_user and specific asset to which access was allowed to be granted to. Only the existence of this valid entry grants permission for Registered_user to do activity within the scope of the authorization (access the specific asset). Doing this, Registered_user becomes Asset_user and can access the asset in accordance with asset user agreement.
In some cases, processes Registration and Authorization can be joined into one which allows to grant permission to accessing the asset directly.
After finishing processes of Registration and Authorization, the System is set to control and grant the access for the specified Applicant to specified asset.
ACTIVITY: REVOKING ABILITY TO ACCESS THE ASSETsetting up the System
As processes of Registration and Authorization allow to grant the permission to accessing the asset for specific Supplicant, there are complementary two which cancel this option:
Their behavioural description is as follows:
Nature of Deauthorization process is inverse to Authorization. During the process, one specific entry is invalidated or removed from Database_of_authorizations causing to revoke permission for accessing the specific asset for Asset_user. This particular Asset_user will not be able to reach the asset in the following attempts anymore as process Authorization_check will keep on failing. Asset_user is degraded down back to Registered_user as well.
Function of process Deregistration is inverse to the Registration. Its goal is to remove specific Registered_user from the System. During the process, one specific entry of Virtual_entity with its Virtual_identity is invalidated or removed from Database_of_registered_users which represents specific removed Registered_user. After the process, owner of deleted Virtual_entity cannot be authenticated in process of Authentication anymore as he cannot claim his Identity to non-existing Virtual_identity (relationship 1:1).
TASK: CLAIMING THE ACCESS TO THE ASSET:operating the System
Fig. 4: Procedure for accessing the asset
There is Entity of Supplicant, who has the role of Claimant.
(default status): At the beginning, Claimant (represented by entity of Supplicant) is in state of Anonymous_claimant, who wants to access the specific asset at the moment.
After the successful process of Authentication, Identity of Anonymous_claimant is revealed which transforms Anonymous_claimant to Authenticated_claimant.
After the successful process of Authorization_check, Authenticated_claimant becomes Authorized_claimant.
These processes are further described in behavioural manner in the following sections:
Purpose of process Authentication is to prove an Identity of Anonymous_claimant. For properly working access control, it is necessary to determinate exact Identity of demanding Claimant.
Process of Authentication per se is claiming specific Virtual_identity and its proving with a method agreed beforehand. One of its form can be e.g. by submitting login (attribute of Virtual_identity) and secret password which would be known only by owner of Virtual_identity. Submitted data for claimed Virtual_identity are verified against the Database_of_registered_users by the System.
In case of failure, claimed Virtual_identity has not been proven by Anonymous_claimant and Anonymous_claimant remains in this role status.
Purpose of process Authorization_check is determination of right for accessing the asset for its possessor: if Authenticated_claimant was authorized for accessing the asset. As Authorization_check works solely with Authenticated_claimants, it is a crucial need for proper function of foregoing process of Authentication.
Process of Authorization_check itself is lookup for entry of authorization inside Database_of_authorizations. Lookup verifies presence of valid authorization entry for Registered_user (represented by Authenticated_claimant identified in the previous step) and specific asset which would permit Claimant for accessing desired asset.
After successful process of Authorization_check, Authenticated_claimant will become Authorized_claimant in the System. Authorized_claimant is always permitted for accessing desired specific asset.
Accessing the asset is an activity which usually immediately follows after successful Authorization_check.
Accounting is a process monitoring the asset for access of individual specific Asset_users.
Once access of Authorized_claimant is technically made by e.g. starting downloading the file, beginning the phone call, withdrawing the money from the account, etc., exact time of the access is recorded to the Database_of_accounting along with Virtual_identity of Authorized_claimant, type of specific asset and many other details describing the nature of the access for further logging and accounting purposes.
Result of Accounting process is information about past activities of Asset_user which could lead to further processes such as monitoring, statistics and even billing, etc.
ATTACKS AND EXPLOITATIONS
The main task of access control system is to control the access to the assets and grants only those Supplicants, who have been authorized for such action. Therefore, attack is an action or series of actions, which lead to unauthorized access.
Beside brute-force attack (e.g. force to break the jail bars, brute-force attack to Asset_user's password, etc.) which leads to compromised element and broken System as a whole unit, and attacks focused on flawed design (e.g. improper design of authentication algorithm, unencrypted communication, etc.), there are at least two main types of attack to deceive the access control systems:
1_A. using a fake Virtual_identity
Attacker undertakes the Registration process, receives an authorization from Authority and gets ability to access the desired asset which he uses subsequently. However, information from Accounting process points out at Virtual_entity which has not Identity of its original owner. Therefore attacker will gain the access to the asset and e.g. does not need to pay the bill.
Method: Eve undertakes the Registration process using fake Identity e.g. "Bob". After that, Bob receives an authorization to access desired specific asset by Authority. In the following steps Eve commences an attempt to access the asset using fake identity of Bob. Passing through the Authentication and Authorization_check processes with Bob's Virtual_entity, Eve gets a granted access to the asset. System monitoring tool solely sees Bob, who claims his right to accessing the asset. As "Bob" is authorized for such an action, Eve gets to the asset. This particular access is recorded by Accounting process to Bob's debit.
System is prone to mistakes or frauds without proper Identity approval during Registration process.
1_B. misuse/theft of Virtual_identity
Attacker uses someone else's Virtual_identity for accessing the asset. cause: Attacker needs to get Proving_factor for claiming and proving someone else's Virtual_identity during Authentication process.
Method: Eve already got Alice's Proving_factor by unspecified way. Eve accesses the asset claiming Alice's Virtual_identity with Alice's Proving_factor. Authentication of Alice is successful and System sees Alice despite Eve's presence in behind. As Alice's role status is Asset_user, this particular access to the asset is granted and Eve gets to the asset in a name of Alice.
An Accounting process records this particular access to Alice's debit.
Attack of this kind is possible in case that attacker is able to somehow obtain Proving_factor of eligible Asset_user.
2. misuse of Authorization
Attacker is somehow able to authorize himself for ability to access the asset. While claiming the access to the asset, the Systems grants him as he is seen as authorized Asset_user.
Method: Eve is somehow able to create authorization entry in Database_of_authorizations. Afterwards, she claims the access to the asset. She is subsequently authenticated and authorized due that newly created entry, therefore she obtains permission for the access. An Accounting process records this particular access to Eve's debit.
For better clarity and documentary purposes it is appropriate to implement some journaling procedure which logs every step made in the settings of the System.
As seen above, access control system works properly in all three cases in accordance with its function. Despite that, asset was accessed by unauthorized External_entity.
In case of method 1_A, proper precaution could be used as verification and proving methods for Applicant. Therefore Applicant in the Registration process will need to prove his Identity in a trusted manner. This method is not a technical vulnerability of the System but loose option of administrative policy strictness.
Both 1_B and 2 methods were committed outside the System. For that reason, there is an importance for securing elements outside the System as well.
In case of 1_B, there is a need for more effective precautions against the theft of user's Proving_factor.
For another case (2), there is a need for better security procedures with proper constrains of a list of Entities, who can create/modify an authorization entry.
The methods described above are only elementary - they can be modified, extended or combined with one another. They do not deal with details such as flaws of specific elements used inside the System (e.g. implementation flaw of encrypting algorithm), neither wrong design of System architecture, nor brute-force attacks.
For proper functions of access control system, it is vital to act in accordance with law during its operation, and use its available tools (such as contracts, agreements, etc.) as particular elements of the System to its advantage. Main reasons are such as contract settlement, protection of property (asset) and identity (Identity of Supplicant).
Every access control system is as secure as its particular elements. All of them should be appropriate to the value of asset they are dealing with, as a quotation about chain's weakest link applies here as well.
In these days, many access control systems are implemented using electronic components, e.g. electronic attendance systems, enterprise ICT systems, computer networks, even different services on the internet. They consist of various architectures with mixed elements, however the principles described in this paper still work inside them in such manner.
 VLČEK, L. Podstata bezpečnosti a riadenia prístupu k aktívu. Access Server, 2014, vol. 12, n. 8, p. 1-5. ISSN: 1214- 9675.
Autor: L. Vlček
Pracoviště: Vysoké učení technické v Brně
Projekty a aktuality
Výzkum a vývoj nového komunikačního systému s vícekanálovým přístupem a mezivrstvovou spoluprací pro průmyslové aplikace TA02011015
Vývoj adaptabilních datových a procesních systémů pro vysokorychlostní, bezpečnou a spolehlivou komunikaci v extrémních podmínkách VG20122014095
Výzkum a vývoj datového modulu 10 Gbit/s pro optické a mikrovlnné bezdrátové spoje, FR-TI2/621
Sítě s femtobuňkami rozšířené o řízení interference a koordinaci informací pro bezproblémovou konektivitu, FP7-ICT-2009-4 248891
Ochrana člověka a techniky před vysokofrekvenčním zářením, FI-IM5/202
Radou pro výzkum a vývoj jako recenzovaný časopis
Pokročilá optimalizace návrhu komunikačních systémů pomocí neuronových sítí, GA102/07/1503
01.07.2006: Doplnění sekce pro registrované
12.04.2005: Zavedeno recenzování článků
30.03.2005: Výzkumný záměr
Výzkum perspektivních informačních a komunikačních technologií MSM6840770014
29.11.2004: Přiděleno ISSN
04.11.2004: Spuštění nové podoby Access serveru
Optimalizace přenosu dat rychlostí 10 Gbit/s, GA102/04/0773
Specifikace kvalitativních kritérií a optimalizace prostředků pro vysokorychlostní přístupové sítě, NPV 1ET300750402
Omezující faktory při širokopásmovém přenosu signálu po metalických párech a vzájemná koexistence s dalšími systémy, GA102/03/0434
Tento web site byl vytvořen prostřednictvím phpRS - redakčního systému napsaného v PHP jazyce.
Na této stránce použité názvy programových produktů, firem apod. mohou být ochrannými známkami
nebo registrovanými ochrannými známkami příslušných vlastníků.