Protecting Against Privilege Escalation

When we talk about system security, we are talking the main components of our environment. Our data and files reside on some systems. Because of that, security of those is important to be maintained. Threat and Vulnerability are inherent to all systems. They are everywhere. One of those is privilege escalation.

Privilege escalation is an exploitation of vulnerability when someone gain privileges other than what originally intended for him. This means that he is able to access the system using other accounts for his benefit. There are two types of it, vertical and horizontal.
 
Vertical Privilege Escalation
This happens when an attacker uses a vulnerability in the system to gain privileges above what is intended for him. This could be damaging the system or stealing information.
 
Horizontal Privilege Escalation
This happens when an attacker uses a vulnerability in the system to gain privileges of another user who has the same privilege as him. For example, John and Liz both are users under financial departments. Both have access to payment data. John may attempt to gain Liz access so that he can amend some payment data but the system logs Liz as the one who do it.
 
How to protect our system from Privilege Escalation
The most common vulnerabilities that can lead to this are Cross-site Scripting (XSS), Improper Cookie handling and weak passwords. These are protection we have to do:

Validate inputs

System creates, maintains, and destroys cookie properly

Avoid to use weak password

Implementing a rule to force user to use complex or strong password and set password age limits

Implementing separation of privilege principle. It is dividing a system into smaller parts and each of those parts has specific duties to perform.

Implementing least of privilege principle. This suggests that software modules or processes only have rights to perform the actions intended to be done by that module or process.

Design Authorization or Access Control System

Authorization and Authentication mostly come in pair. Layered upon authentication, authorization is a process to confirm that an authenticated entity has the needed rights and privileges to access and perform actions on resources. It is Access Control job to carry out authorization policy. There are three main access control model used today.

Discretionary Access Control (DAC)

Mandatory Access Control (MAC)

Role-Based Access Control (RBAC)

 
Each has its own advantages and disadvantages. Some organizations may choose and use multiple access control models that fits to their particular systems or environment.

Before we discuss more detail about those, we need to identify the Subject and Object first. Subject is an entity that is requesting access and Object is resource that Subject will act upon. Subject can be a human user or a system process.

Discretionary Access Control (DAC)

DAC restricts access to objects based on the identity of the subject and is distinctly characterized by the owner of the resource. He/She has right to decide who can access and what level of privileges or rights is given. Usually, it is implemented using Access Control Lists (ACL). The relationship between the individuals (subjects) and the resources (objects) is direct and the mapping of individuals to resources by the owner is what constitutes the ACLs. This method can be integrated with Role-Based Access Control. In this case, we map between user’s roles (as Subject) and resources.

This is an example for Access Control List from Windows.

 

Mandatory Access Control (MAC)

MAC is based on hierarchical model. Access to objects is restricted to subjects based on the sensitivity of the information contained in the objects. The sensitivity is represented by a level and label. All users are assigned a clearance level and all objects are assigned a security label. In this case, access is determined based on matching a subject’s clearance level with the object’s sensitivity level.

For example, we have data and its categories are top secret, secret, confidential, internal and public. We also have clearance levels are chief department, manager, supervisor and ordinary users. A manager has rights to access all data with secret category and below. Chief department has rights to access all available data. And ordinary users can only access internal and public data.

In this model, access is controlled by the administrator and it can be quite cumbersome to manage. An administrator can quickly become overwhelmed as the systems grow more complex. It is disadvantage to MAC model.

Role-Based Access Control (RBAC)

So far, it is common model I used in my systems. Access is given based on roles instead of individual user. And those role are managed by the administrator. The administrator determine all available roles within his organization and then map those to job functions and tasks.

What this mainly provides is that the resource is not directly mapped to the Subject but only to the role. Since individuals can change over time, while roles generally don’t, Subject can be easily assigned to or revoked from roles.

How to design Logging feature

Logging is an important feature and must be available in the system. It will be useful for auditing purpose. Some applications I ever developed do not have an interface for user to configure this feature. So, team who maintains it has a responsibility to get the records directly from its storages (e.g. database or files).

There are may benefit to have logs. It captures all information about what the user is doing in the system, e.g. adding a new record, etc. It also captures all exceptions or errors thrown either from application itself or the system environment.

Please take note that hacker is able to manipulate the logs. He usually amends or remove some entries/record in the logs to hide his action after he exploit the system. In this case, we need to think thoroughly when designing logging feature in a system.

Let us see what is a minimum requirement for logging feature.

There is an interface to configure setting for logging. User should be able to configure these settings:
a. Turning on/off logging feature in which environment(s) (e.g. development, test, production, etc)
b. What kind of information that can be logged (e.g. application events, operating system events, error/exception, etc)
c. The verbosity of the logs (e.g. info, error, warning, etc)

Only authorized users have access to change the configuration setting for logging.

Logs are never overwritten and can only be appended to. If you have an issue with capacity, the logging verbosity needs to planned carefully.

There is no delete function to delete any entries/records in logs.

 
Now, the choice is yours regarding how you will implement your logging feature in your system.

Secret Key Management Framework

If your application manages sensitive data, the main challenging task during design phase is choosing cryptographic techniques. First, we must understand your business requirement regarding how the system should process with those data. We have to think through not just how to store it but I mean the whole processes. It can be when data are transferred from one point to another point or during processing in server memory.

In Cyber Security, we know this term, Code Breaking. Have you ever watched Tom Cruise breaks secret code in his Mission Impossible movies? Or, You may have a dream to be James Bond, where secret messages is uncovered through some clever techniques. Wait a minute.. do you think that it is so easy? Sorry, the answer is NO.

Cryptanalysis is a knowledge of finding vulnerabilities in cryptographic. That techniques are used by hacker to try break secret code. We can also use it with the intention to uncovering and addressing any weakness in our cryptographic. It is useful that we have and implement the knowledge of it during design phase. What should we consider?

It is critical to put work factor as our consideration when choosing a cryptographic techniques. Work factor is an effort (with available resources) to break protection mechanism. Please take note that work faction is exponentially dependent on the key size or key length. It is measured in bits or bytes. And it contains a sequence of symbols that we use for encryption and decryption processes. So, it means that we have to keep our key secretly.

To break secret code, a hacker need time and computational power. All cryptographic algorithms (by right) can be broken, except for one-time-pad. So, how do we make sure that our key is kept securely? This is Key Management Framework that is taken from Official (ISC)2 Guide To the CSSLP CBK.

To protect the secrecy of our key, we extremely need a good key management. From CSSLP guideline, we can see that key management life cycle starting from generation, exchange, storage, rotation, archiving and destruction. Key must be random during generation. That is a main criteria. Then, it must be protected when it is shared so that it not disclosed to anyone who are not eligible to have it. We also need to prepare properly a place where we store that key. It can be a hardware security module (HSM) such as the Trusted Platform Modules (TPM) chip.

We also need to do rotation or change our key regularly with a new one. The change is also need to be done immediately upon key disclosure. Before we discard old key, we need to decide whether we have to archive it in another secure place. We do this because there are some data in our system are using it as key during encryption and description. If we want to keep our data as it is, that means we need to archive that old key. Otherwise, we have to decrypt our data and encrypt again using new key. If the key is destroyed without being archived, the corresponding key to decrypt the existing data will be unavailable. It is leading to a denial of service (DoS) should there be a need to retrieve the data for forensics or disaster recovery purposes.

Put security in mind when designing a software

When you develop a software, it can meet all quality requirements but it does not guarantee that it is secure. However, if we put security in mind during design phase, it become an added value to increase the quality of your software. Let’s see what benefit we get if we do this.

We can say that design phase is starting phase to implement all requirements stated in requirement specification. A good software does not come from good and secure code only. It also comes from good design. If we always implement or practice to put security concept when designing our software, it becomes less prone to errors. Anyone who maintains this software will be very happy because it is easy to be maintained. Again, this condition improves the quality of your software, right?

The other benefit is that we are able to detect every business flaw early. For example, there is a requirement for password recovery. Previously (or it may still be practiced nowdays), we encounter that some sites are using question and answer model to recover user’s password. The drawback of this model is that hacker’s has an ability to guess the answer because the number of answers are limited. Questions about mother name or when user born are easy to get from Facebook. That is the power of social media. Hackers can use social engineering techniques to retrieve all personal information of his target from social engineering. Another question that is easy to be guessed is what color user likes. The answers are limited to common colors that we know. In this case, we need to find other solution for this so that it is difficult for hacker to guess.

At the end, we can have time and cost saving since there is minimal-to-no disruption to business operation.

What do you have to know about build process?

The build process here is a conversion process from source code to object code that the machine can understand. The integrity of this process can be assured by:

• Only authorized users have access to the system where source code is stored.
• Version control must be applied to make sure the right version deployed on Production environment.
• Sometimes, we are using a build script to automate the process. It is important that security controls are not circumvented.

The important thing about this process is important to ensure that there is no new vulnerabilities are introduced. The main kinds of build tools to get code ready for deployment are packagers and packers. Packagers are tools to build software (including its dependencies and resources). For examples The Red Had Package Manager, the Microsoft Installer and Java Packager Tool. Packers are tool to compress executable for distribution purpose.

Please take note that a hacker also uses packers to pack their malware. He uses the same process to transform executable appearance. It is done to avoid signature-based malware detection tools.

Are you sure that you are using secured third party libraries?

Are you sure that you are using secured third party libraries?

Hmm… another question… Does big name always bring secure product? I can answer.. maybe yes.. maybe no.

However, for sure, you must do your own research before putting third party libraries into your application. I give you one example. Your application processes sensitive information and put those in a database. You use third party libraries to retrieve data before doing some other processing in your logic. How do we make sure that those third party libraries are secured enough?
Remember, those libraries are transferring our sensitive information. It is quite risky if we do not find any information about it.

One way that you can do is searching in vulnerability databases and tracking systems. Now, there are many systems provide information about product vulnerabilities.

The National Vulnerability Database (NVD)

NVD is the U.S. government repository of standards based vulnerability management data represented using the Security Content Automation Protocol (SCAP). This data enables automation of vulnerability management, security measurement, and compliance. NVD includes databases of security checklists, security related software flaws, misconfigurations, product names, and impact metrics.

US Computer Emergency Response Team (CERT) Vulnerability Notes Database

The CERT Knowledgebase is a collection of internet security information related to incidents and vulnerabilities.

Open Source Vulnerability Database

It is an independent and open-sourced database that provides accurate, detailed, current, and unbiased technical information on security vulnerabilities.

Common Vulnerabilities and Exposures (CVE)

Common Vulnerabilities and Exposures (CVE®) is a dictionary of common names (i.e., CVE Identifiers) for publicly known information security vulnerabilities.

Common Weakness Enumeration

It is targeted to developers and security practitioners, the Common Weakness Enumeration (CWE) is a formal list of software weakness types created to:
a. Serve as a common language for describing software security weaknesses in architecture, design, or code.
b. Serve as a standard measuring stick for software security tools targeting these weaknesses.
c. Provide a common baseline standard for weakness identification, mitigation, and prevention efforts.

Quality and Security

What is a distinction between quality and security?

In every software development, all software must go through a quality assurance (or testing) before being released or deployed. At this phase, all functionalities are validated and verified. There are two purposes:
a. All functions must work properly as designed
b. All functions must meet the requirements as specified in requirement specification

Some software also go to follow quality processes and certification (e.g. Six Sigma). It will prove that quality standard has been applied during development.

However, we must understand that those processes do not mean that the software is secure. A software product that is secure will add to the quality of that software but the inverse is not always necessarily true. It is also important to recognize that it does not guarantee that the software is secure when the software has security feature.

In order to develop hack-resilient software, it is important to incorporate security concepts in all software life cycle ( requirements, design, code, release and disposal phases).

Holistic Security

Secure software is characterized by the securing of application, hosts and network holistically.

Currently, there is no software deployed as a stand-alone business application. It is quite complex, running on host systems that are interconnected to several other system on a network. A weakness (vulnerability) in any one of the layers may affects other layers.

For example, there is a web application running on a machine. It is also accessing a database machine. If a hacker is able to exploit the application using SQL Injection technique, the impact to that network is in danger. It is because a hacker is able to compromise database server and launch attack to entire network.

So, secured software contributes to the security of entire computing ecosystem. What attributes makes insecure software?

a. Iron Triangle Constraints
During software development, there are three major constraints to be managed. Those are scope, budget and schedule. Adding security into the software is seen as having the need to do ‘more’ so it is the reason why security requirements are left out of the software.

b. Security as an Afterthought
Developers and management tend to think that security does not add any business value since it is not very easy to show a one-to-one return on security investment. Please take note that addressing vulnerabilities just before a product is released is very expensive.

c. Security versus Usability
Implementing secure features is viewed as rendering the software to become very complex, restrictive and unusable. Now, many banking applications implements two-factor authentication. It is an enhancement security feature compare to previous time when username and password were quite enough for authentication process. With this approach, either using token or receiving password through SMS on mobile phone, it increase inconvenience among customers. In this case, we need to factor in or implement the concept known as psycological acceptability. Software security must be balanced with usability and performance.

Flaws versus Bugs

What is Flaws? What is Bug? Are those same?

First, we look at the whole picture when security issue happens. It does not always relate to insecure coding or implementation.It can be because of architecture issue. So, definition of flaws and bugs can be referred to where those are generated. The important thing here is both need to be identified and addressed appropriately.

Flaws are errors produced by design and architectural defects. It can also be business logic flaws. This kind of errors is difficult to be detected when we do code review. Scanners, Intrution Detection Systems (IDS) and application-layer firewalls cannot detect and protect tha application against this kind of errors. Threat modelling and secure architecture design reviews are useful processes to detect any architecture defects.

Bugs are errors produced during coding or implementation. Easy ways to detect this kind of errors are code review, scan source code and penetration testing after implementation. Sometimes, we can also see that some coding bugs are inherited from architectural defects, such as insufficient input validation and improper error and session management.