Unit 5: Securing Applications and Data

1. How adversaries reach files (5.1.A)

2. How application attacks exploit vulnerabilities (5.1.B)

An application is a program that runs instructions on a computer: it is executable data. Some run locally on the user’s computer; others, like web applications, run on a server and are reached over a network 5.1.B.1.

Many applications take user input in open-ended fields where users type letters, numbers and punctuation. Developers should check that input matches what is expected, for example only digits when the field asks for a number of items, and reject anything outside the expected parameters. Checking input before processing it is data validation. Applications that fail to validate input are vulnerable to injection-type attacks, where adversaries insert unexpected character strings to change how the program behaves 5.1.B.2.

SQL injection

Structured query language (SQL) requests information from databases and changes databases and their entries. An application that builds a database query from unvalidated or unsanitized user input is vulnerable 5.1.B.3. An SQL-injection attack places SQL commands and control characters into an input field. It can breach confidentiality (the application returns more information than it should) or integrity (data in the database are modified or deleted) 5.1.B.4.

input typed:  x' OR 1=1 --
query built:  SELECT * FROM members WHERE card = 'x' OR 1=1 --'
# the quote closes the text early, OR 1=1 is always true,
# and -- turns the rest into a comment: every member comes back

Cross site scripting (XSS)

Websites are written in hypertext markup language (HTML), and many use JavaScript for dynamic content. JavaScript runs in the visitor’s browser, so it can reach sensitive data stored there, such as usernames, passwords and cryptographic keys 5.1.B.5. A cross site scripting (XSS) attack injects malicious code into a website that the user’s browser then runs 5.1.B.6:

Buffer overflow

When an application takes input, the input is written to a buffer: a set section of memory with a fixed size. Input larger than the buffer can overflow into the next memory locations and overwrite other parts of memory 5.1.B.7. A buffer overflow attack feeds in more data than was allotted. It can crash the system, or make it run code outside the program’s security policy, letting the adversary access, modify or delete files 5.1.B.8.

Directory traversal

The files that run a web application sit in directories on a server. Browsers request them with hypertext transfer protocol (HTTP) GET requests, and each GET request reaches a file somewhere in the server’s file system 5.1.B.9. In a directory traversal attack, adversaries edit URLs and GET requests to try to reach sensitive data, such as usernames and passwords, elsewhere on the server 5.1.B.10. Each ../ moves up one directory:

GET /recipes/photos/soup.jpg                     # expected
GET /recipes/photos/../../../backups/users.csv   # climbs 3 folders up, then into backups

3. Assessing and documenting data risks (5.1.C)

Data security risks hit confidentiality when unauthorized people can access sensitive data, integrity when data can be manipulated or altered, and availability when data can be destroyed or encrypted so others cannot reach them 5.1.C.1.

Now audit a file server the way an analyst would.

1. Data state and classification (5.2.A)

Organizations apply specific security controls to comply with legal requirements, based on the types of data they collect, store, process and transmit 5.2.A.1. Data can be classified by their state 5.2.A.2:

Organizations also categorize data by sensitivity and give more sensitive information a higher degree of security 5.2.A.3. Laws and regulations can require certain data to be stored, transmitted and handled by specific rules 5.2.A.4:

Organizations that collect regulated data label them and keep policies that meet the legal or regulatory rules for storing, transmitting and handling them 5.2.A.5.

2. Managerial controls for applications and data (5.2.B)

3. Access control models (5.2.C)

Access control enforces which users or applications (subjects) can access, modify, add or remove (operations) which files or applications (objects). An access control model describes how to decide which subjects get what access to which objects 5.2.C.1.

The Bell-LaPadula model is a MAC model often used by governments and militaries 5.2.C.6:

1. Simple Security Property: subjects may not read objects above their level.
2. * (Star) Security Property: subjects may not write to objects below their level.

Together: write up, read down (WURD). A Secret-level analyst can read Confidential reports and can write to a Top Secret file, but cannot read Top Secret or write to Confidential.

The principle of least privilege: give each entity exactly as much access as it needs to perform its function, and no more 5.2.C.7.

4. Linux permissions (5.2.D)

Authorization is when an entity is granted permission for a certain type of access to a resource; access controls decide which users have which types of access to which data 5.2.D.1.

Linux has three permissions, always in this order 5.2.D.2: read (view the contents), write (change the file) and execute (run a binary such as a program), shown as rwx. A - means the permission is absent, so read and execute only is r-x. They are set for three entities, always in this order, with no spaces 5.2.D.3: the file owner, the file group and all other users, as in rwxrwxrwx.

$ ls -l
-rw-r-----  1 records doctors 8204 Nov  9 08:02 patients.csv
-rwxr-xr--+ 1 itadmin it     512 Nov  9 08:05 sync.sh
#  owner group others  (+ means extra permissions: run getfacl sync.sh)

ls -l shows the settings; a + at the end means other permissions are set, viewable with getfacl 5.2.D.4. chmod changes them, with the numeric or the symbolic method 5.2.D.5.

Practice choosing the model, then set real permissions with the drop-down menus.

1. How encryption protects files (5.3.A)

The purpose of cryptography is to hide information. A cryptographic algorithm defines how to encrypt (hide) and decrypt (reverse the encryption to get the original back) 5.3.A.1. An encryption algorithm combines the information with a predefined key. The input is the plaintext; the output is the ciphertext 5.3.A.2.

The number of possible keys an algorithm can use is the keyspace. The larger the keyspace, the longer it takes an adversary to find the correct key by random chance 5.3.A.3.

2. Symmetric encryption with AES (5.3.B)

Computer-based encryption works on binary data. The most common symmetric algorithm is the Advanced Encryption Standard, used to secure Wi-Fi transmissions, internet browsing, file encryption on disks and hardware-level encryption on processors 5.3.B.1. AES is a symmetric key block cipher that encrypts data in 128-bit blocks (16 bytes). It can use keys of different lengths; longer keys are more secure but take more time to encrypt and decrypt 5.3.B.2.

You can encrypt and decrypt from the command line with OpenSSL, with specialized software such as the open source AES Crypt, or with web-based tools 5.3.B.3. In OpenSSL the key is derived from the password you provide 5.3.B.4:

# encrypt grades.csv with AES and a 256-bit key
$ openssl enc -aes-256-cbc -e -in grades.csv -k RiverStone93 -out grades.csv.enc
# decrypt: same cipher, -d, the same password
$ openssl enc -aes-256-cbc -d -in grades.csv.enc -k RiverStone93 -out grades.csv

Build the commands with the drop-down menus, then encrypt and decrypt your own message.

1. Which key to use (5.4.A)

Asymmetric encryption lets users communicate securely without prearranging a shared secret key 5.4.A.1. Every entity that will receive data first generates a key pair: two binary strings of equal length, generated at the same time by a mathematical process. One is the public key, the other the private key. The keys are mathematical inverses: either one can encrypt, but only the other key in the pair can decrypt 5.4.A.2.

The receiver must store the private key securely. If it is exposed, shared, stolen, corrupted or compromised, the key pair must be deleted and a new pair generated, because the security of the algorithm rests on the private key. The public key is published for anyone to view and use 5.4.A.3.

To send information securely, the sender encrypts with the receiver’s public key. Only the receiver, who has the private key, can decrypt and read it 5.4.A.4.

2. Why key length matters (5.4.B)

Longer keys give larger keyspaces. An n-bit key has a keyspace of 2ⁿ 5.4.B.1. Guessing randomly, an adversary finds the right key in 2ⁿ/2 = 2^n-1 guesses on average 5.4.B.2.

Each extra bit doubles the keyspace. Longer keys are more secure but take more time to encrypt and decrypt 5.4.B.3. Computing power keeps improving, so key-length recommendations for symmetric and asymmetric algorithms are raised periodically 5.4.B.4. Key lengths can be compared only for the same algorithm: a longer AES key beats a shorter AES key, and a longer RSA key beats a shorter RSA key, but an RSA key and an AES key cannot be compared by length 5.4.B.5.

3. Applying asymmetric encryption (5.4.C)

Common asymmetric algorithms are RSA (named after its inventors, Rivest, Shamir and Adleman) and elliptic curve cryptography (ECC). They are used in many applications, including digital signatures and digital certificates 5.4.C.1. As with symmetric encryption, you can use the command line (OpenSSL), specialized software such as the open source RSA Encryption Tool, or web-based tools 5.4.C.2. With OpenSSL 5.4.C.3 (PEM, privacy-enhanced mail, is the text format the key files use):

Pick the right key for each step with the drop-down menus, then run a real key pair in your browser.

1. Secure by design and secure by default (5.5.A)

Secure by design is an initiative that encourages companies to include security in all phases of product development, including design. Security becomes a design principle, not just a technical feature 5.5.A.1. It has three principles 5.5.A.2:

Secure by default is part of secure by design: security features of software and devices are enabled by default, so products are secure to use out of the box 5.5.A.3. A new smart speaker that forces you to set a unique password at first start, with automatic updates already switched on, is secure by default; one that ships with a shared factory password and updates turned off is not.

2. Input sanitization (5.5.B)

When users type into an application, it usually wraps the input in special characters to process it. These control characters include the single quote, the double quote and the semicolon 5.5.B.1.

expected:  ... WHERE city = 'Lisbon'
typed:     Lisbon'; DELETE FROM bookings; --
becomes:   ... WHERE city = 'Lisbon'; DELETE FROM bookings; --'
# the quote ends the text, the semicolon starts a new command

Programmers should use a verification function to check that input meets the expected criteria and contains no control characters that could manipulate the system. The function can sanitize the input by removing potentially malicious characters, or give the user an error and make them enter different input 5.5.B.2. For example, removing or encoding the < and > characters means a <script> tag can never form, and removing ../ stops a path from climbing directories. This protects against:

• SQL injection attacks
• Cross site scripting (XSS) attacks
• Directory traversal attacks

Review real form submissions below and decide which ones the verification function should stop.

1. Detecting attacks on data (5.6.A)

Devices track and log when data are accessed and by whom. Recording and monitoring user activities is accounting. Analyzing these logs can reveal an adversary trying to access, copy, move or delete data 5.6.A.1. Suspicious activity includes:

• Accessing files that are not typically accessed
• Accessing files or applications outside a user’s normal patterns: time of day, location and device type
• Attempts to delete or copy sensitive files

A honeypot is a file that looks as if it holds valuable data (such as credit card information, personally identifiable information (PII) or passwords), but the data are fake. Because there is no legitimate reason to open it, any attempted access is an indicator of malicious activity, and the system can alert defenders 5.6.A.2. Cryptographic hash functions generate a digest for data and reveal if the data have been altered; an unexpected change can be a sign of malicious activity 5.6.A.3.

2. Choosing detective controls (5.6.B)

3. Judging a detection method (5.6.C)

4. Verifying a hash (5.6.D)

Hash functions are repeatable: the same input always gives the same output for a given function, so a change in the hash means a change in the file 5.6.D.1. Hashes can be calculated on the command line, on a website or with specialized software 5.6.D.2:

Hash a file and record the output; hash it again later and compare. If the hash changed, the file was altered between the two hashes 5.6.D.3.

$ sha256sum policy.pdf          # March: recorded
5d41b0f2...3c9a  policy.pdf
$ sha256sum policy.pdf          # June: compare
a77e0913...e012  policy.pdf     # different: the file was altered

5. Reading application logs (5.6.E)

Each line of a web server log records the time, the source internet protocol (IP) address, the request and a status code. Read the user input inside each request.

Work the logs below the way a security operations analyst would.