Computer security: informatica, Sintesi del corso di Informatica gestionale

Scarica Computer security: informatica e più Sintesi del corso in PDF di Informatica gestionale solo su Docsity!

S. Williams, B. Lawrie,

Computer security

INTRODUCTION

CIA paradigm: they are three basic requirements that a secure system must accomplish: ● CONFIDENTIALITY: information can be accessed only by the authorized entities ● INTEGRITY: information must be modifiable only by entities who have the right to do, and only in the way they are supposed to do it. ● AVAILABILITY: information must be available to all the entities who have the right to access them AVAILABILITY conflict with CONFIDENTIALITY conflict with INTEGRITY. Some basic definition: ● asset: An asset is what an organization think is valuable and that needs to be protected ● vulnerability: it is a design bug (cause the system is not well-designed) in the security system which allows to violate one or more points of the CIA paradigm ⎛ eg. Software that fails to check the size of attachments ● exploit: it is a specific way to violate one or more point of the CIA paradigm through a system vulnerability ⎛ eg. a PDF attachment that leverage a certain vulnerability ● threat: whoever/whatever may cause an attack to occur ● attack: An intentional use of one or more exploits to violate the CIA through one or more vulnerabilities ● risk: A statistical and economical evaluation of the exposure to damage because of the presence of vulnerabilities and threats. It's always associated to amount of damage/value of the asset ● trusted element: in every security system we must establish one or more elements that we assume to be secure. ⎛ Can we trust of the security officer? ⎛ Can we trust the software we just bought? ⎛ … So on and so forth RISK = ASSETS x VULNERABILITIES x THREATS The first two variable are controllable whereas the last it is not. (Indipendent variable) Security is the balance between reduction of vulnerabilities, damage containment and costs, which can be divided into two groups: ● DIRECT COSTS: ⎛ equipment ⎛ management ⎛ operational ● INDIRECT COSTS (often more relevant) ⎛ less usability ⎛ less privacy

CRYPTOGRAPHY

cryptosystem: It's a system that given an input message (called plaintext ) and a secret code (called key ), through a reversible algorithm ( cipher ) returns an encrypted message ( ciphertext ) Kerckhoff's principle The security of a cryptosystem must only rely on the secrecy of the key, and never on the secrecy of the algorithm used. Three important consequence of the Kerckhoff's principle are: ● It's impossible to retrieve a plaintext from a known ciphertext without the key ● It's impossible to retrieve the key from a couple plaintext-ciphertext ● The algorithm used must always be assumed to be known to the attacker Shannon's theorem In a perfect cipher, the number of the possible keys (called key-space) must be greater or equal than the number of possible messages (message-space)

|K| >= |M|

NB: In the real world, of course, there are not perfect cipher, because the message-space is always larger than the key-space, so it is always possible to break a cipher through brute force (given a ciphertext, try all the possible keys until you obtain a plaintext that makes sense) Normally, a real (not perfect) cipher is broken if there is an easier and faster way to break it than through brute force. There are three different kind of attacks: ● ciphertext attack: the cryptoanalyst has only some ciphertexts ● known plaintext attack: the analyst has a set of pairs plaintext-ciphertext ● chosen plaintext attack: the analyst can choose plaintexts and obtain their relative ciphertexts. Key points: ● A security of a cryptosystem is based on the robustness ● No algorithm, save the OTP, is invulnerable ● There's no way to prove the robustness of a cipher ● Secret algorithm is not secure

ONE TIME PAD

It's a minimal perfect cipher because the key space = message space, based on the login XOR between a plaintext m and a random key k (of the same size of m) obtaining the ciphertext c. 16 byte of m XOR 16 byte of k The key is pre-shared by the parties, and must be deleted after the use (it cannot be reused!!). It's not a real world cipher(even if used in some special situations) because it's terribly incovinient: you need a different key for each message of the same length, and a different set of keys for each possible message length. NB: OTP are not vulnerable to brute force, because every ciphertext decrypts to every possible plaintext (if we try all the possible keys to decrypt a ciphertext, we obtain all the possible plaintexts!). Could be vulnerable only if we know what the context is.

We have to keep in mind this summary: REAL |K| < |M|

ONE TIME PAD

|K| = |M|

PERFECT

|K| > |M|

SYMMETRIC CIPHERS - Confidentiality

It is an algorithm in which the message is encrypted with a key k by the sender, sent over an untrusted channel to the recipient, and then the same key is used to decrypt the message. This cipher could also be called shared key encryption or secret key encryption. In this kind of encryption there is a problem called the key-sharing problem: the key must be shared between the two parties over a trusted channel. Usually, a symmetric cipher is a mix of two ingredients: ● SUBSTITUTION : replacing each byte with another one. The key is an integer number (K=3) Possible issues may derive from the fact that substitution conserves the structure and repetitions of characters of the plaintext in the ciphertext, and that the key-space is relatively small. ⎛ eg. substitute every alphabetical character with the one positioned three spots later “SECRET” > “VHFUHW” ● TRANSPOSITION : swapping the values of given bytes. Now the structure and repetitions of the plaintext are not visible anymore, but we still have a relatively small key-space ⎛ eg. Put the message in a 4x2 matrix, writing it by rows, and then reading it by columns “MESSAGE” > “MSAEESG”

Another famous example of asymmetric cipher using the same trick (one-way trapdoor) is the RSA (Rivest-Shamir-Adelmann), which is based on the factorization problem: given two large primes p and q it's easy to compute n = p * q , but knowing n it's computationally intensive to compute its prime factors. Factorizing a number n is exponential in the number of bits of n. Computational time for encryption grows linearly in the number of the bits. Nowadays, we cannot factorize anything larger than 600 bits. The problem is easily solved because our key size is greater than 1024 bits (typically 2048/4096 bits). NB: It is a different problem from the diffie-hellman but can be shown they are related (it is related to DSS too). ECC is currently the strongest algorithm and it is completely different from the others. ATTENTION: Key length In both symmetric and asymmetric ciphers, the length of the key (measured in bits) its really important, but it has a different meaning in each case: ● SYMMETRIC: it measures the number of decryption attempts needed. ●ASYMMETRIC: it measures the number of key-breaking attempts Furthermore: ● You can compare symmetric algorithm through their key lengths ● You cannot compare asymmetric algorithm through their key lengths ● you never compare symmetric and asymmetric algorithm through their key lengths (Symmetric keys (128/256 bits) are less powerful than asymmetric (2048/4096) )

HASH FUNCTIONS - Integrity

An hash function is a function that maps an arbitrary-length input x in a fixed-length output h. A perfect hash function would be injective, but normally it's not the case because the co-domain is smaller than the domain, so we have the collision phenomenon: it is possible that two inputs x and y have the same hash h. A good hash function should satisfy these three major properties:

1. first pre-image attack resistance : it's “computationally unfeasible”, given an hash h , to compute x such that H(x) = h. With a n-sized hash function, random collisions can happen in (2^(n - 1) ) cases. 2. second pre-image attack resistance : it's “computationally unfeasible”, given an input x, to compute y s.t. H(x) = H(y). With a n-sized hash function, random collisions can happen in (2^(n - 1) ) cases. 3. collision resistance : it's “computationally unfeasible” to generate, more easily than randomly, couples [x,y] s.t. H(x) = H(y). Random collisions can happen in (2 n/2 ) cases because of the birthday paradox. Hash function can be very useful, for example to securely store passwords or confidential data, or to guarantee authenticity and integrity of a message (used in combination with asymmetric encryption) though the so-called digital signature. Commonly Used Hash Functions : ● SHA-1 (160 bit output) ● SHA-2 (256) ● MD5 (128)

DIGITAL SIGNATURE AND CERTIFICATE AUTHORITIES – Confidentiality,

Integrity and Authentication Asymmetric algorithm and hash function can also be used in combination to solve two important problems in exchanging cryptographic messages: ● AUTHENTICATION: how can you be sure that a message you received was really the one sent you from one of your friends, and not a replaced one by an attacker? ● INTEGRITY: how can you be sure that a message you received has not been modified or forged? The solution is to to sign (through encryption with your private key) the document you are sending, so that the recipient can be sure about who sent it (by decrypting it with your public key). In this way you assure authentication. If you hash your message, before signing and sending it to the recipient, and then send also the normal message (so that the recipient can hash it and then compare the result with the decryption of the previous message), you can also assure integrity. This method guarantees authenticity and integrity of the message, and also secrecy can be guarantee (you just have to apply an encryption algorithm to the message before hashing it). PROBLEM: Digital signature guarantees only that the document were signed with a specific key, but it does not say anything about who is using that key. We need something (a trusted party) that associates keys with identifies, ie. To create a public key infrastructure (PKI) for exchanging safely public keys. This trusted third party is called Certificate Authority (CA), and its task is to issue certificates (which associate an identity with a public key) signed with its own private key (so that everybody can verify the authenticity of the certificate through CA's public key). NB: Certificate chain : If the CA has its own public key, there must be a certificate related to it (associating it with the CA identity). But who is signing this certificate? Another CA? So we will have a certificate chain, and it must stop at some point. We need a trusted element called Top Level CA (root CA, source CA) which uses a self-signed certificate that

2. Firma&Cifra: creation and verification of a signature with a fake certificate. In order to verify a signature, we need author certificate and the certificate chain. The certificate chain is, theoretically, all available online. To allow offline verification , everything is included with the document, in a PKCS#7 standard envelope. Firma&Cifra trusts the root certificate in the PKCS#7 envelope, and it even imports it in the secure storage area. ⎛ Generate a fake root certificate with the same name as a real one (e.g., PostECom itself) ⎛ Use this to generate a fake user certificate (in our example Arsène Lupin) ⎛ Use Arsène Lupin's certificate to sign theft and burglary confessions. ⎛ Include the fake root certificate to the PKCS#7 envelope.

THE “to be” FACTOR – the entity has to prove that it has a specific characteristic (fingerprints,

voice/face recognition...). ● ADVANTAGES : ⎛ guarantee an high level of security ⎛ don't require extra-equipment to carry around ● DISADVANTAGES : ⎛ Bio-characteristic can change

⎛ Non-deterministic matching ⎛ Hard to deploy ⎛ Can be cloned ⎛ Users with disabilities ● COUNTERMEASURES : ⎛ Re-measure often ⎛ Make the process more secure and less invasive

SINGLE SIGN ON

PROBLEM

Managing and remembering multiple passwords over many sites can create lots of problem because humans are inherently unable to keep secrets and they find hard to remember complex password. As a result, users will re-use the same password (possibly, an easy one) over multiple sites, creating a security problem. SOLUTION A possible solution is to select a trusted host which will be the one to which users have to authenticate. Then, all the other host will ask to the trusted one if the user is authenticated or not yet. INSECURITIES ● Single point of trust: if the truster server is compromised, then all the system is compromised ● Password reset scheme : if an user has to reset or change his password, the procedure must be bulletproof, or it will compromise the entire system. ● Hard to deploy: the flow of data is really hard to implement

● ROLE-BASE ACCESS CONTROL (RBAC): is simply an hybrid of DAC and MAC

BELL-LAPADULA MODEL

It's a combination between DAC and MAC models: ● MAC rule 1 (no read up) ● MAC rule 2 (no write down) ● DAC rule (access control matrix) With BLP, the secrecy levels of objects cannot change dynamically. This model prevents information flowing down from an high security level to a lower one. The disadvantage is that it cannot copy or declassify objects and subjects. It does not address integrity.

As seen before, if we try to run the executable with user bar, we should expect the EUID = bar. Because the SUID, once you run executable , you detect that the EUID != bar , further more:

bar == RUID != EUID == foo

Suppose, we change the owner to ROOT and we set the SUID bit. Every user able to run the executable has privileges root. What if the executable is vulnerable? A best practice is to drop the privilege once you do not need it anymore (The EUID should be changed back once the privileged instructions are done). We reduce the probability that an attacker perform bad action removing the root privileges in read and parse. NB: THIS DO NOT MEAN THAT WE ARE SAFE, DO_THINGS MAY CONTAIN VULNERABILITIES. KEY ISSUES IN SECURE PROGRAMMING: ● Reduce privileged parts to a minimum ● KISS (Keep It Simple, Stupid) ● discard privileges (i.e. SUID->RUID) as soon as possible ● open design: security must not rely on obscurity Remember that bug-free software does not exist, but not all bugs lead to a vulnerability, and then an exploit is needed to become a threat! Zero-day means vulnerabilities that are not publicly disclosed yet.

MEMORY ERROR VULNERABILITIES

While writing a program, we use variables to contain some values we need to manipulate, and we allocate memory locations (buffers) for those variables.

BUFFER OVERFLOW

A buffer overflow is when someone assign a value to a variable which is larger than the memory buffer previously allocated for that variable. In this way some memory locations, not allocated for that variable, will be overwritten. Unintentional buffer overflows can make a program crash, while an attacker can intentionally run a buffer overflow attack, modifying security-relevant data or running some malicious code. An example of buffer overflow attack is called stack smashing attack , and it is based on the stack of an operating system. Usually the attacker's goal is to inject executable code (shellcode) into a running program, taking over the process and gaining this way unauthorized access and privileges. DEFENDING AGAINST BUFFER OVERFLOW ● Defense at source code level: finding and removing vulnerabilities ⎛ C/C++ does not cause buffer overflow. Stupid programmers cause buffer overflow ⎛ Education of developer ⎛ Using safe libraries, hence str n cpy, str n cat ● Defense at compiler level: making vulnerabilities not exploitable ⎛ Randomized reordering of stack variables ⎛ Embedding stack protection mechanisms at compile time ♠ Verifying during the epilogue that the frame has not been tampered ♠ Usually a canary is inserted between local variables and control structure such as SAVED EIP and SAVED EBP ♠ When the function ends, the canary is checked and, if tampering is detected the program is killed (this is exactly what StackGuard does) ● Terminator canaries : made with terminator characters (typically \0) which cannot be copied by string copy functions and therefore cannot be overwritten ● Random canaries : random sequence of bytes, chosen when the program is run ● Random XOR canaries : It's the same of above, but canaries XORed with part of the structure we want to protect ● OS level defense ⎛ Non-executable stack stops shellcode from being run from the stack, making a stack smashing attack useless. Actually there are still some programs which need executable stack to run (JVM older version) ⎛ Address layout randomization : makes harder for the attacker to guess the position of the return address, repositioning the stack among other things at each execution

FORMAT STRINGS BUGS

These attacks are based on the malicious use of FORMAT STRING and PLACEHOLDERS (which are commonly used, and intended to specify how date are formatted to a string). An attacker can use %x and %s to read data from the stack, or use %n and %c to write arbitrary data on arbitrary position