Why are your linux files secure?

Transcription

1 Security Page 1 Why are your linux files secure? Thursday, November 29, :48 AM Why are your linux files secure? Part 1: the concept of identity. user, group,... Part 2: the concept of protection. the protection word: rwxr-xr-- Part 3: mutating protections (legally). chmod, chgrp (chown) Part 4: mutating protections (illegally).

2 Security Page 2 chmod, chgrp, chown Wednesday, December 6, :29 PM Protection manipulations require that one owns the inode. chmod {octal number} {file or directory} "change mode": set protection for thing. chgrp {group name} {file or directory} change group chown {user name} {file or directory} change ownership (root only)

3 Security Page 3 What you don't want to see in your account Wednesday, November 30, :56 PM What you don't want to see in your account: foo mode=rwsrwsrwx owner=root group=root Setuid root Setgid root world executable Whoever runs this gets root on your workstation. What a rootkit actually does, in some form: cp /bin/csh foo chown root foo chgrp root foo chmod foo so that anyone who runs foo gets a root shell. Almost as bad: for a normal user: cp /bin/csh bar chmod bar so that anyone who runs bar gets access to your account. This just requires your privilege, not root.

4 Security Page 4 The chain of privilege Sunday, December 04, :36 PM The chain of privilege People login as users, which have groups and own files, which determine what the user can do. Privilege can only be changed via processes. which can run with privileges of the invoker (default) or the owner (or group) (setuid, setgid) of the file that is run.

5 Security Page 5 A misconception on the midterm Wednesday, December 04, :28 PM Many people thought that one's privileges are related to parent-child relationships. This is false. The owner of a process retains powers over it, even if it becomes a child of init. The process has the concept of userid (which determines who can send signals to it) and the concept of groupid (which determines which group owns files that it creates). It is ownership of the process that determines who can manipulate it.

6 Security Page 6 How login works Tuesday, December 06, :10 AM How login works: login is run by root. accepts your password. hashes it. compares with (protected) hash of real password (in /etc/shadow or similar). If there is a match, then: fork a child downgrade child privilege to that of user (setuid, setgid, seteuid, setegid) execl the user's shell from the child.

7 Security Page 7 Security and Privacy Wednesday, November 30, :02 PM Security and Privacy Security: you control the things you own. Privacy: it is not seen by others without your permission. In an OS, these are (nearly) equivalent concepts. Two other important concepts Identity: the extent to which the actions of an electronic entity can be traced to a real person. Transparency: the extent to which we can see what people do. Basic problem of security: the internet exhibits weak identity and low transparency.

8 Security Page 8 Two levels of security/privacy Sunday, December 04, :55 PM Two levels of security/privacy in an operating system: Account security: can others control your (personal) account? OS security: can others control your operating system itself? Both of these involve giving a process permissions that it does not deserve.

9 Security Page 9 What can a regular user do? Sunday, December 04, :16 PM What can a regular user do? Grant anyone the power to become the user. Set traps for other users. Set up a rogue network service. Attack other machines (in the local network). Poison DNS, ARP, etc. Send containing malicious code to others.

10 Security Page 10 What can root do? Tuesday, December 06, :39 PM What can root do? Compromise the accounts of all users. Become any user and do anything. Corrupt services used by external machines. Poison the basic infrastructure of the internet.

11 Security Page 11 Warning: the law and cracking Sunday, December 04, :09 PM Warning: the law and cracking The things I will now describe are illegal. I do not condone these things. You should not engage in them. But you must know what others can do to you.

12 Security Page 12 Protecting yourself Sunday, December 04, :56 PM Protecting yourself Assume nothing. If it looks too good to be true, it is. Understand that people can do anything, Even very implausible things.

13 Security Page 13 An aside: human factors of security Wednesday, December 04, :02 PM According to a 2007 study, "Do you want to allow this software to make changes?" is -- in the minds of most users -- semantically equivalent to "Do you want to get your work done, or not?" Weakest link in any system is the human user.

14 Security Page 14 Social engineering Sunday, December 04, :01 PM Social Engineering A professional hacker's most effective tool. Convince others that you are someone you're not: A microsoft technical support specialist. An amazon technical support person. An ebay technical support person. (Use your imagination) In the natural course of playing that role, trick your victims into compromising their security and privacy: By running untrusted software. By disclosing their passwords, either directly or indirectly.

15 Security Page 15 Security Myths and Realities Sunday, December 04, :50 PM Security Myths and Realities Myth: The main cause of security breaches is technical. The most effective attacks trick the machine. The most effective attack vector is a software weakness. Reality: The main cause of very serious security breaches is human error. The most effective attacks trick users. The most effective attack vector is to con a user into believing something that isn' t true. Cracking is a confidence game.

16 Security Page 16 Hacking versus cracking Sunday, December 04, :56 PM Hacking versus cracking Hacking has a positive and a negative connotation: Positive: someone who writes mystically powerful code. Negative: someone who breaks into computers. Cracking is less confusing: No positive connotation. Breaks into computers, by any means necessary. Not even necessarily a good programmer.

17 Security Page 17 Why crackers crack? Tuesday, December 06, :35 AM Why do crackers crack? Illusion of power. Curiosity. Hatred. Money. What do crackers want? Anonymity. to send Spam to attack other machines. CPU cycles. to run bots and other interesting software. Bandwidth. to run bots and other interesting software.

18 Security Page 18 Principles of effective cracking Wednesday, November 30, :06 PM Principles of effective cracking 1. Don't get caught. 2. In pursuit of (1), obfuscate your identity as much as possible. a. By using exploited systems to exploit others. b. By using exploits that do not require human interaction. 3. Exploit the weakest links: a. Poorly configured systems (and networks) that aren't adequately protected. b. Naïve users who will believe what you tell them. c. Previously exploited systems.

19 Security Page 19 Cracking skills Tuesday, December 06, :15 AM Cracking skills Anonymity: ensuring that your own physical identity is safe. Leapfrogging: using a previously exploited system to break into another. Patience: waiting (perhaps) a long time for results. Curation: filing lists of exploits, systems that can be exploited, and previously exploited systems for future use. Scanning and fingerprinting: determining lists of systems on which an exploit is likely to work. Poisoning: utilizing one exploit to set a (more deadly) trap. Track covering: hiding what you have done to a system.

20 Security Page 20 Hiding identity Sunday, December 04, :14 PM Hiding identity Your identity is as secure as the number of people who have to collaborate to discover it. Especially if those people don't get along. International discord is a cracker's best friend. Ideal scenerio Break into a system in South Korea. From there, break into a system in North Korea. From there, break into a system in the United States. I call this the "principle of social distance".

21 Security Page 21 Reverse Social Engineering Sunday, December 04, :04 PM Most sophisticated attack vector: reverse social engineering Research what software is used in the site. Fake a major distribution of the software; when installed, it breaks the system. Publish the real phone number of the vendor on the fake. Crack the victim's phone system (a weak point) and redirect the real vendor phone number to you. Send the distribution to the victim with the authentic phone number. So, victim installs software, calls vendor, gets you. At this point, you are in a near-perfect cracking situation Victim will swear that you're official; they have "proof"; they called the official number themselves! You are -- in fact -- a slimeball intent on stealing their secrets.

22 Security Page 22 Technical cracking Sunday, December 04, :04 PM Technical cracking Not the big issue in cracking. But a constant nuisance, because a bored 14-year-old can exploit a technical problem. And there are lots and lots of bored 14-year-olds!

23 Security Page 23 Three ingredients Wednesday, December 04, :34 PM Three ingredients Set of exploits Set of fingerprinted machines (they have the capabilities required by the exploit). Tools for computing fingerprints. Previously exploited machines.

24 Security Page 24 Kinds of technical cracking Tuesday, December 06, :03 PM Prevalent kinds of technical cracking Bug exploits. Dictionary attacks. Poisoning.

25 Security Page 25 What is a (technical) vulnerability? Sunday, December 04, :05 PM What is a (technical) vulnerability? Unpredictable user input provides unintentional access. Typical example: buffer overflow attack. Cause: programming that doesn't protect against arbitrary inputs. These vary in severity programs run by normal users: compromise the user account. programs run by root: compromise the system itself.

26 Security Page 26 Buffer overflow attacks Sunday, December 04, :07 PM Buffer overflow attacks Recall that each stack frame contains Local variables. Return addresses. What you might not realize is that: You can overwrite these in upper (earlier) frames from a mistake in a lower (later) frame. You can point return addresses at arbitrary code!

27 Security Page 27 gets is the root of all evil Sunday, December 04, :09 PM gets is the root of all evil gets(buf): reads to end of line, potentially past end of buffer. fgets(buf,len,stdin): reads to either end of line or end of buffer. So, why don't we just rewrite everything? Footprint: millions of lines of code. Subtlety: it is possible to embed a gets-like behavior in other code.

28 Security Page 28 Monday, December 7, :13 PM Two basic exploits stack buffer overflow: points the return value of a frame at unknown machine code. heap buffer overflow: corrupts a pointer to function to point to unknown code. Super specific: tailored to application, os, and version. dependent upon stack layout, buffer size, and many other things. Finger printing: matches super-specific hacks to super-specific systems.

29 Security Page 29 stack overflow attack Tuesday, December 06, :16 PM stack buffer overflow attack Find an input statement without buffer limit. Engineer machine code to put into the buffer. Make input long enough to overwrite the stack frame return pointer (in your frame, or in the previous (upper) one). So that on return, it executes the code you wrote rather than returning! Exploit code already in memory to pursue your attack.

30 These are the amateurs Wednesday, December 6, :01 PM The real crackers use techniques that are much more insidious. End of lecture on 12/6/2017 Security Page 30

31 Security Page 31 Buffer overflow attack vectors Tuesday, December 06, :46 PM Buffer overflow attack vectors User programs. Web sites. Network services (run as root -- yum!)

32 Security Page 32 Properties of a stack overflow attack Tuesday, December 06, :17 PM Properties of an overflow attack Application-specific: only one application. Build-specific: depends on structure of compiled program. Doesn't work if used on any other application or any other build of the same application. (Can break things). Fingerprinting is important: it determines where an exploit will work. Fingerprinting: Using a program to determine the specific configuration of a system, including installed programs and versions.

33 Security Page 33 "systems monoculture" Wednesday, December 04, :46 PM Systems tend to converge -- on a worldwide scale -- to a single build, so that being able to attack one of them makes one able to attack all of them. -- Dan Geer

34 Security Page 34 Exploiting the systems monoculture Tuesday, December 06, :19 PM Exploiting the systems monoculture Stack buffer overflow attacks exploit a systems monoculture: Everyone installs the exact same application program. If the program has a vulnerability, everyone gets that vulnerability.

35 Security Page 35 Countermeasures Tuesday, December 06, :50 PM Countermeasures for buffer overflow attacks Frequent patching for discovered overflow vulnerabilities. System fingerprinting to detect changed files. System scanning for compromised (setuid) files.

36 Security Page 36 Doctor, it hurts if Tuesday, December 06, :32 PM Doctor, it hurts if I do this Then don't do that! It isn't that simple. Millions of lines of contributed code. Indirect buffer overflows: lack of protection occurs in an unpredictable place.

37 Security Page 37 Fuzzing Sunday, December 04, :24 PM Best defense against buffer overflow: fuzz testing Generate random inputs. Classify behaviors. Identify potential overflow behaviors. See

38 Security Page 38 Heap buffer overflows Tuesday, December 06, :48 PM Heap buffer overflows: A program writes into a heap buffer. Input that is too long overwrites other structures. Including structures containing, e.g., function pointers. Result: when function pointer is invoked, the wrong function is called.

39 Security Page 39 Poisoning Tuesday, December 06, :22 PM Poisoning Use one successful exploit as the basis for another. Set up an environment in which users do one thing and have another happen. Three examples: Path poisoning DNS poisoning ARP poisoning

40 Security Page 40 Path Poisoning Tuesday, December 06, :24 PM Path Poisoning Get users to execute a malicious program by putting it into their execution paths. It is named like a regular program: a "trojan horse". Example: "ls" that isn't the real "ls". Malicious program compromises the account of the user. potentially installs still more malicious information. Paydirt: if root executes a trojan, system is compromised. You might have noticed that '.' is not in your execution path. This is why you have to execute./a.out rather than a.out. This is also why a malicious person cannot fool you into executing his own./ls.

41 Security Page 41 DNS Poisoning Tuesday, December 06, :27 PM DNS Poisoning DNS = Domain Name Service = the service that maps from internet names to internet numbers. Fool a system into calling up a malicious system instead of google.com. Malicious system tries to install malware. You think it's google, so you press "OK".

42 Security Page 42 ARP Poisoning Tuesday, December 06, :28 PM ARP Poisoning ARP = address resolution protocol = protocol that maps from internet addresses to local (ethernet) addresses. In the local network, you contact system X and get system Y. Often used to accomplish DNS poisoning by pointing at a local rogue DNS server that the cracker set up.

43 Security Page 43 Why is poisoning possible? Tuesday, December 06, :54 PM Why is poisoning possible? The internet was designed as a "trusting" system. There is no provision for establishing authenticity of a network entity. Further, this naive trust is necessary for proper network operation -- more on this in COMP112.