Quiz1

Question 1

Security Impact for the company

Answer 1

the important thing to understand here is that no company is safe from a breach, and many companies that we interact with on a daily basis have suffered security breaches.

Question 2

security mindset, we need to consider:

Answer 2

• Threats (who are the bad actors?)
• Vulnerabilities (what weaknesses can they exploit?)
• Attack (how will the bad actors exploit the weaknesses?)
Athreat sourcerefers to an individual or entity that wishes to do us harm in our online lives.

Question 3

An example of a vulnerability

Answer 3

a weak password. A threat actor can likely guess a weak password, and use that password tocompromiseyour account.

Question 4

security breach

Answer 4

If the threat actor is able to compromise an entire digital system instead of just a single account - by gaining access to a centralized server or database,

Question 5

Can we get rid of vulnerabilities compeletly

Answer 5

Unfortunately, vulnerabilities are very hard to get rid of completely. They are found in software, networks and, frequently, humans.

Question 6

When thinking about security breaches there are different questions to ask:

Answer 6

• What is of value?
• What is the threat source?
• What vulnerability was exploited?
In this attack, the information of value was credit card data that was available on the point-of-sale systems present in Target stores.
The threat source was cybercriminals wishing to profit off of this information.

Question 7

What Should We Do in Cyber Security?

Answer 7

1. We can try to make threats go away. This is not an easy feat to achieve, but we can try to discourage criminal activity by introducing computer abuse laws.
2. We can reduce vulnerabilities, but we are never going to have zero vulnerabilities. Complex systems are error-prone, and some of those errors will expose vulnerabilities that can be exploited.
3. If the data is sensitive in the sense that it cannot be disclosed to unauthorized parties, then aconfidentialityrequirement is present.
4. If no one should be able to modify or corrupt the data, the data is said to have anintegrityrequirement.
5. If the data is critical in the sense that we must always have access to it - your bank account data, for instance - then the data has anavailabilityrequirement.

Question 8

Integrity

Answer 8

If no one should be able to modify or corrupt the data, the data is said to have anintegrityrequirement.

Question 9

confidentiality

Answer 9

If the data is sensitive in the sense that it cannot be disclosed to unauthorized parties, then aconfidentialityrequirement is present.

Question 10

availability

Answer 10

If the data is critical in the sense that we must always have access to it - your bank account data, for instance - then the data has anavailabilityrequirement.

Question 11

Data breaches violate which of the following security requirement?

Answer 11

confidentiality

Question 12

How Do We Address Cyber Security?

Answer 12

1. One way to reduce vulnerability is to follow design principles that are good for security.
2. Economy of mechanismmeans the design of security measures built into the system should be as simple and small as possible.
3. Fail-safe defaultmeans that access decisions should be explicitly granted rather than explicitly denied.
4. Complete mediationsays that every access to a resource must be checked against the access controls. No access should proceed unmonitored.
5. Open designmeans the design of a security mechanism - for example, encryption algorithms - should be open rather than secret. Security by obscurity is a false promise.
6. Psychological acceptabilitymeans that security mechanisms should not interfere unduly with the work of users, while at the same time meet the needs of those who authorize access. Security mechanisms that excessively hinder the usability or accessibility of resources are likely to be turned off.

Question 13

buffer overflow

Answer 13

A buffer overflow occurs when the amount of memory allocated for a piece of expected data is insufficient (too small) to hold the actual received data. As a result, the received data “runs over” into adjacent memory, often corrupting the values present there.
stack buffer overflowsare buffer overflows that exploit data in thecall stack.

Question 14

call stack

Answer 14

During program execution, astackdata structure, known as the call stack, is maintained. The call stack is made up ofstack frames. When a function is called, a stack frame is pushed onto the stack. When the function returns, the stack frame is popped off of the stack.
The stack frame contains the allocation of memory for the local variables defined by the function and the parameters passed into the function.

Question 15

function call

Answer 15

A function call involves a transfer of control from the calling function to the called function. Once the called function has completed its work, it needs to pass control back to the calling function. It does this by holding a reference to thereturn address, also present in the stack frame.

Question 16

Stack buffer overflows

Answer 16

Stack buffer overflows can be exploited through normal system entry points that are called legitimately by non-malicious users of the system. By passing in carefully crafted data, however, an attacker can trigger a stack buffer overflow, and potentially gain control over the system’s execution.

Question 17

two things you can do with a stack

Answer 17

push and pop

Question 18

stack grows

Answer 18

when something is pushed onto it

Question 19

stack shrinks

Answer 19

shrinks when something is popped off of it.

Question 20

current “top” of the stack

Answer 20

The current “top” of the stack is maintained by a stack pointer, which points to different memory locations as the stack grows and shrinks.

Question 21

stack flow direction

Answer 21

We can assume that the stack grows from high (numerically larger) addresses to low (numerically smaller) addresses. This means that the stack pointer points to the highest memory address at the beginning of program execution, and decreases as frames are pushed onto the stack.

Question 22

password overflow

Answer 22

If the user enters a password longer than 12 bytes, the remaining bytes will overflow into the memory allocated toallow_login, effectively overwriting its value.

Question 23

Attacker Code Execution

Answer 23

If the attacker guesses the correct password and types that as input to the program, login will be allowed.
If the attacker guesses the wrong password - which fits into the allocated buffer - there will be no overflow and login will be rejected.
These are the two basic outcomes for a naive attack: either the attacker guesses correctly and access is granted or the attacker guesses incorrectly and access is denied.

Question 24

memory bites

Answer 24

allowLogin(4 bytes),pwdstr(12 bytes) andtargetpwd(12 bytes)

Question 25

vulnerabilities happen when

Answer 25

The code didn’t check the input and reject the passaword longer than 12 bits. The overflow happens precisely because input larger than the space allocated for that input is not rejected by the program.

Question 26

target password

Answer 26

The target password can be as long as you’d like, but if the attacker submits a longer password, the overflow will still happen.

Question 27

useless variables

Answer 27

Besides the fact that you shouldn’t ever really add useless variables, these variables will only provide a finite amount of distance between the user-filled buffer and the return address. With a long enough password, the attacker can still overwrite the return address.

Question 28

execve,

Answer 28

which replaces the currently running program with the invoked program - in this case, the shell at/bin/sh.

Question 29

Shellcode Privileges

Answer 29

The vulnerable program is running with some set of privileges before transfer is controlled to the shellcode.
When control is transferred, what privileges will be used?
The shellcode will have the same privileges as the host program. This can be a set of privileges associated with a certain user and/or group. Alternatively, if the host program is a system service, the shellcode may end up with root privileges, essentially being handed the “keys to the the kingdom”.

Question 30

return-to-libc.

Answer 30

the return address will be modified to point to a standard library function. Of course, this assumes that you will be able to figure out the address of the library function. If you return to the right kind of library function and you are able to set up the arguments for it on the stack, then you can execute any library function any parameters.

Question 31

Heap Overflows

Answer 31

An overflow doesn’t have to occur to memory associated with the stack. Aheap overflowdescribes buffer overflows that occur in the heap.

Question 32

heap overflow and stack overflow

Answer 32

One crucial difference between the heap and the stack is that the heap does not have a return address, so the traditional stack overflow / return-to-libc mechanism won’t work. What we have in the heap are function pointers, which can be overwritten to point to functions that we want to execute.
Heap overflows require more sophistication and more work than stack overflows.

Question 33

OpenSSL Heartbleed

Answer 33

It read past an assumed boundary (due to insufficient bounds checking) and was exploited to steal some important information - like encryption keys - that resided in adjacent memory.

Question 34

Defense Against Buffer Overflows

Answer 34

Naturally, we shouldn’t write code with buffer overflow vulnerabilities, but if such code is out there deployed on systems, we need to find ways to defend against attacks that exploit these vulnerabilities.
For instance, choice of programming language is crucial. There are languages where buffer overflows are not possible.
These languages:
• are strongly typed
• perform automatic bounds checking
• perform automatic memory management
Languages that have these features are referred to as “safe” languages and include languages like Java and C++.

Question 35

Safe Languages

Answer 35

If we choose a “safe” language, buffer overflows become impossible due to the checks the language performs at runtime.
One drawback for these languages is performance degradation. The extra runtime checks slow down the execution of your program.

Question 36

Unsafe Languages

Answer 36

When using “unsafe” languages, the programmer takes on the responsibility of preventing potential buffer overflow scenarios.
One way to do that is by checking all input to ensure that it conforms to expectations. Assume that all input is evil.
Another strategy to reduce the possibility of exploitation is to use safer functions that perform bounds checking for you. One such list of safe replacements for common library functions in C can be foundhere.
A third strategy is to use automated tools that analyze a program and flag any code that looks vulnerable.

Question 37

issue with automated analysis tools

Answer 37

hey may have many false positives (flagging something that is not an issue), and may even have false negatives (not flagging something that is an issue). No tool should replace thoughtful programming.

Question 38

Analysis Tools

Answer 38

These tools analyze the source code of your application, and can flag potentially unsafe constructs and/or function usage. only for source code

Question 39

Stack Canary

Answer 39

We can use astack canary, or a value that we write to an address just before the return address in a stack frame. If an overflow is exploited to overwrite the return address, the canary value will be overwritten with it. All the runtime has to do, then, is to check if the canary value has changed when a function completes execution. If so, it can be sure that there is a problem.
What is nice about this approach is that the programmer doesn’t have to do anything: the compiler inserts these checks. Of course, this means that the code may have to be recompiled with a compiler that has these features, a step which may come with its own issues.

Question 40

ASLR

Answer 40

The first technique that many operating systems use isaddress space layout randomization(ASLR). ASLR randomizes how memory is laid out within a process to make it very hard for an attacker to predict, even roughly, where certain key data structures and/or libraries reside.
Many modern operating systems provideASLRsupport.

Question 41

Non-executable stack

Answer 41

In the classic stack buffer overflow attack, the attacker writes shellcode to the stack and then overwrites the return address to point to that shellcode, which is then executed.
There is no legitimate reason for programs to execute instructions that are stored on the stack. One way to block executing shellcode off the stack is to make the stack non-executable.

Question 42

3 types of buffer over attacks

Answer 42

1. Stack canaries do prevent return-to-libc buffer overflow attacks, because stack canaries prevent return address overwriting. Without overwriting the return address, a function can only return to the function that called it.
2. ASLR does not protect against read-only buffer overflow exploits. ASLR only makes it harder to supply key addresses in write-based buffer overflow exploits.
3. Heartbleed cannot be avoided by using a non-executable stack. Heartbleed is a read-based buffer overflow exploit, and the attack did not involve injecting any machine instructions onto the stack.