Quiz1 Flashcards
L1, L2
Security Impact for the company
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.
security mindset, we need to consider:
• 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.
An example of a vulnerability
a weak password. A threat actor can likely guess a weak password, and use that password tocompromiseyour account.
security breach
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,
Can we get rid of vulnerabilities compeletly
Unfortunately, vulnerabilities are very hard to get rid of completely. They are found in software, networks and, frequently, humans.
When thinking about security breaches there are different questions to ask:
• 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.
What Should We Do in Cyber Security?
- 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.
- 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.
- If the data is sensitive in the sense that it cannot be disclosed to unauthorized parties, then aconfidentialityrequirement is present.
- If no one should be able to modify or corrupt the data, the data is said to have anintegrityrequirement.
- 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.
Integrity
If no one should be able to modify or corrupt the data, the data is said to have anintegrityrequirement.
confidentiality
If the data is sensitive in the sense that it cannot be disclosed to unauthorized parties, then aconfidentialityrequirement is present.
availability
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.
Data breaches violate which of the following security requirement?
confidentiality
How Do We Address Cyber Security?
- One way to reduce vulnerability is to follow design principles that are good for security.
- Economy of mechanismmeans the design of security measures built into the system should be as simple and small as possible.
- Fail-safe defaultmeans that access decisions should be explicitly granted rather than explicitly denied.
- Complete mediationsays that every access to a resource must be checked against the access controls. No access should proceed unmonitored.
- 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.
- 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.
buffer overflow
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.
call stack
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.
function call
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.
Stack buffer overflows
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.
two things you can do with a stack
push and pop
stack grows
when something is pushed onto it
stack shrinks
shrinks when something is popped off of it.
current “top” of the stack
The current “top” of the stack is maintained by a stack pointer, which points to different memory locations as the stack grows and shrinks.
stack flow direction
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.
password overflow
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.
Attacker Code Execution
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.
memory bites
allowLogin(4 bytes),pwdstr(12 bytes) andtargetpwd(12 bytes)
vulnerabilities happen when
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.
target password
The target password can be as long as you’d like, but if the attacker submits a longer password, the overflow will still happen.
useless variables
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.
execve,
which replaces the currently running program with the invoked program - in this case, the shell at/bin/sh.
Shellcode Privileges
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”.
return-to-libc.
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.
Heap Overflows
An overflow doesn’t have to occur to memory associated with the stack. Aheap overflowdescribes buffer overflows that occur in the heap.
heap overflow and stack overflow
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.
OpenSSL Heartbleed
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.
Defense Against Buffer Overflows
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++.
Safe Languages
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.
Unsafe Languages
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.
issue with automated analysis tools
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.
Analysis Tools
These tools analyze the source code of your application, and can flag potentially unsafe constructs and/or function usage. only for source code
Stack Canary
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.
ASLR
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.
Non-executable stack
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.
3 types of buffer over attacks
- 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.
- 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.
- 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.
