Download Audio: M4A
A man-in-the-middle attack occurs when a snoop eavesdrops on a connection by making independent connection with the victims and relays messages between them. To protect against these attacks, we can encrypt packets, but this costs time. Thus, it is more popular in practice to use private networks.
When logging in from multiple clients, the user may have mismatching uids in the different clients. Thus, even in the same network, the user would be re-authenticated to gain access. Thus, there needs to be a way for secure network authentication.
A malicious can pretend to be a server, tricking other clients. One of the more popular ways of comabtting this is using Kerberos Authentication.
For example, when someone pulls a gun out on you.
For example, when someone steals your banking information and uses your information to steal your money.
For example, when someone watches you through your window to see what you are doing. This attack may be considered second order.
Example: Unauthorized information release, including passwords and other sensitive information
Example: Tampering of data, including deletion of files, changing grades, and other unwatned actions
Example: Denial of Service attack, an attempt to make the machine or resource unavailable to all users
Protects against Privacy and Integrity attacks
Also protects against Privacy and Integrity attacks.
Protects against Service attacks
The first step in the design process for security is defining possible threats by looking at possible use cases that may be exploited for malicious actions.
Insiders are people who are inside the system, but have gone bad. For instance, a retiring professor may have had access to other classes' grades. Leaving with a bad note with the university, he decides to change the grades of random students in other classes. This would be considered an insider attack. This is the main threat for many systems.
Social engineering is the art of manipulating people into performing actions and/or divulging confidential information. One example of this happening would be Kevin Mitnick, widely considered the most infamous hacker in Los Angeles history. Kevin's hacking specialty was considered to be phone systems, stealing long distance calls and listening to other people's conversations. How did he do this? Kevin simply called the phone system and asked for the password to the telephone pole near his victims. The support line on the other end knew Kevin was at the telephone pole from his request, so they assumed he was a repairman who needed the password for a repair. Surprisingly enough, this type of attack is fairly common and successful.
Worms and viruses are two well-known types of network attacks. The network attacks that are most popular now are drive-by downloads. Drive-by downloads offten occur by an unsuspecting victim viewing a malicious website or email-adress and/or by clicking on a misleading pop-up window/advertisement. Some ways people try to circumvent these attacks are disabling javascript entirely or with browser extensions such as No Script. Denial of Service attacks also fall under network attacks.
Device attacks include USB viruses and viruses on other external devices. For example, usb drives with viruses may be left on the floor for unsuspecting victims to pick up and connect to a computer.
Authentication checks to see if the user is who they say there are. Passwords are assumed to suffice for authentication: if you have the correct password, you are who you say you are.
We must ensure that data is not tampered with. To do this, we use a checksum to reassure the data is not changed.
Assuming we have solved the authentication problem (with the password), we must now authorize the user to only do certain things. We do this with permissions (read, write, execute). More on permissions later, in the authorization section.
To clean up and diagnose attacks after they have happened, access logs are used to analyze the attack.
When implementing our security, we have to do everything such that it doesn't slow down too much. But how much is too much?
We must ensure that our system works correctly. Must account for abstraction and modularity.
With diect access, we map into the address space. Here, we can use ordinary loads and stores. Each access is checked by hardware. However, when you get a fault, a fault handler is under software control, so you can do fancier things. This is the faster method, but it is not very extendible.
char *p = mmap(fd,offset, size, ...)
With indirect access, we don't map into address spaces, but hace service requests via handles (opaque objects). Unlike direct access, each request is handled by software. Thus, indirect access leads to lots of flexibility and finer grained control.
fd = open(file, ...)
read(fd, ...)
We can store the permissions in a three dimensional array. However, this takes up a lot of bits. To combat the bit usage, we could group together files, users, and even accesses.
for each user:
for each file:
for each type of access network(r,w,...):
check if allowed
The UNIX approach to authorization involves a two dimensional array in which each file contains a list of user/permissions.
for each file:
look at list of user/permissions
The getfacl command displays the file name, owner, the group, and the ACL. Notice below the extra permissions for the user das and the group tas. This helps with scaling and sharing at larger levels, but is more complicated.
$ getfacl
user: rwx
user:das: r-w
group: r-x
group: tas: rwx
other: r-x
Role based access is better for large organization. For role based access, the user can assume a role for each access. This prevents a malicious user from gaining complete control.
fd = open("xabc", O_RDONLY)
$ ls -l
-rwsr-xr-x ...
How is it possible to get an s when it is represented by a single bit indicating if there are execute permissions? There are three hidden bits before the well know "755" bits. These three bits are represented by the setuid, setgid and sticky bits (in order). A 4755 would cause the s to appear and likewise a 4655 would cause a capital S. What does this mean? If the setuid is set, upon execution of the program, the program runs as the owner of the file. An example of this would be /bin/passwd. This avoids the need for daemons.
Daemons running as root must be trusted. Other code that must be trusted include: /bin/passwd, login, device drivers, kernel. It is ideal to keep the list of code that has to be trusted as small as possible. We want things like gcc, emacs, oracle, mysql, etc. to be outside of the TCB, the Trusted Computing Base.
if(strcmp(user,"ken")==0)
uid = 0;
However, this code can be easily seen and questioned. Thus, he could have generated the code in the compiler, CC:
if(compiling(login.c))
generate strcmp
This code can be seen easily, too. So what if he inserted code when compiling CC itself to generate the CC code. This process could continue, hiding the inserted code. Ken Thompson didn't actually do this, but the question is remains: how do we know that this does't exist in Windows or Unix or any other system we use?