View source for Courses/Computer Science/CPSC 601.29.ISSA.W2011

== Information Systems Security Analysis wiki: Winter 2011 ==

This wiki serves the Information Systems Security Analysis (i.e., "Ethical Hacking") graduate seminar course started in the Winter of 2011. Students will post their vulnerability identification assignments and their literature reviews here.

The course Web site is located at: [http://pages.cpsc.ucalgary.ca/~locasto/teaching/2011/ISSA/]

== Class Notes ==

=== 12 Jan 2011: Course Introduction ===
*Michael will set up a mailing list for the course for announcements and discussions.
** mailing list is at: http://mailman.ucalgary.ca/mailman/listinfo/cpsc601-29-l
*Please read and sign Agreement linked off course website, submit to Michael on Friday
*Backtrack Linux: http://www.backtrack-linux.org/
*DailyDave mailing list: https://lists.immunityinc.com/mailman/listinfo/dailydave
*read the following papers/sites for Friday:
** Reflections on Trusting Trust http://cm.bell-labs.com/who/ken/trust.html
** The Security Mindset http://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html
** E-Prime for Security, Steve Greenwald, NSPW 2006 (get from the ACM DL or [http://pages.cpsc.ucalgary.ca/~locasto/readings/NSPW2006Greenwald.pdf])
** Some Thoughts on Security After Ten Years of qmail 1.0, DJB, CSAW 2007 [http://pages.cpsc.ucalgary.ca/~locasto/readings/qmailsec-20071101.pdf]
** Why Do Street Smart People Do Stupid Things Online?, Bratus et al. IEEE S&P Magazine May/June 2008 [http://pages.cpsc.ucalgary.ca/~locasto/readings/streetsmart.pdf]
** Security By Checklist, Steve Bellovin [http://www.cs.columbia.edu/~smb/papers/04489860.pdf]

=== 14 Jan 2011: Security Mindset ===
*Discussion of papers from 12 Jan
**Need to develop a security mindset, which means that you simultaneously think about how to deconstruct, analyze, or subject a system to unexpected or malicious inputs and conditions as you build it or design it.
**E-Prime may help provide clarity in certain security scenarios, particularly technical communication or policy writing. YMMV WRT GUI components.
**link to Clark-Wilson Integrity Model (a wikipedia page I edited during writing my dissertation): http://en.wikipedia.org/wiki/Clark-Wilson_model
**interesting experiment: rewrite a selection of security policies and models in E-Prime and survey ~25 security professionals for their impression of clarity, precision, correctness, etc.
**flaws in software (re: trusting trust) (e.g., alleged backdoor in OpenBSD IPsec stack) 
***http://marc.info/?l=openbsd-tech&m=129236621626462
***http://marc.info/?l=openbsd-tech&m=129244045916861&w=2
***http://marc.info/?l=openbsd-tech&m=129296046123471&w=2
*Please join the class mailing list
*Please sign up for an account on the course wiki
*Please obtain a recent Linux environment (Fedora, BackTrack, Ubuntu) either by dual booting, having a LiveCD, or a virtual machine (VMWare, VirtualBox, QEMU, VMWare Player)
*'''Readings for next class''':
**The paper I mentioned about computability of access control model properties: "Protection in Operating Systems" by Michael A. Harrison, Walter L. Ruzzo, and Jeffrey D. Ullman ([http://portal.acm.org/citation.cfm?id=360303.360333 ACM Digital Library], available via U of C with appropriate network address)
**http://www.cs.virginia.edu/~cs216/Fall2005/notes/x86-doc.pdf
** read the following parts of Intel IA32 Developer Manuals, Volume 1: http://www.intel.com/products/processor/manuals/
***Section 2.1 (skim this)
***Section 2.2 (paying particular attention to the description of the pipelined microarchitecture)
***Chapter 3 (paying particular attention to 3.1, 3.2, 3.3, 3.4, 3.7, 3.7.4, 3.7.4.1)

=== 19 Jan 2011: IA-32 Architecture, Basic Process and Binary Inspection ===

The agenda for this class includes:
*Theme Topic for today: the Hacker Curriculum Principle of Inspection (or Visibility): what does this piece of code actually contain, and what does it do at runtime?
*disscussed the literature review project
**2..4 pages of analysis in a systems security topic from 5..10 papers in that area
**check topics list of major security conferences for area/topic ideas
**email the class mailing list with questions or to ask for pointers to papers
*reviewing important points from the readings
**We will cover calling conventions in more detail in a later class
**IA-32 has implicit operands
**AT&T vs. Intel syntax
**variable length instructions
**CISC-style architecture (although microcode translation is to a RISC-like ISA)
**complicated superscalar pipeline
**set of general purpose registers & roles (EAX...)
*some hands-on work with system calls, assembly language, and Unix cmd-line tools:
**strace
**gawk
**hexdump
**ghex2
**objdump
**file
**sort
**uniq
**gcc -S
*Profiling the set of commonly-used x86 instructions (we did this for a Hello, World program, but I challenge you to do it for the glibc.so ELF file on your system):
** awk 'BEGIN { FS = "\t" } ; {print $3}' instructions.out | awk '{print $1}' | sort | uniq -c | sort -nr
** the file instructions.out above was produced from `objdump -d a.out'
*'''Resources'''
**http://bastard.sourceforge.net/libdisasm.html
**http://www.gnu.org/software/gawk/
**http://udis86.sourceforge.net/ (We will use this in our shellcode exercises)
**http://www.nasm.us/ (NASM)
**http://www.nasm.us/xdoc/2.09.04/html/nasmdoc0.html (NASM documentation)
*'''Readings for Friday'''
**http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html

=== 21 Jan 2011: Process and Binary Inspection (ELF toolchain) ===
*We will dissect a C program at many different levels: source, assembly, and ELF binary image. Along the way, we will discover some new tools and various specifications.
** We started off class discussing the "big picture": the major difference (and relationship) between static analysis of the properties of binary images and dynamic analysis of running programs (i.e., processes). The production and processing of each artifact involves a number of other systems, including IDEs, the lexer/parser/compiler, assembler, linker, and the OS loader. Each of these introduces a location for '''instrumenting''' the system.
** ELF Specification: http://www.muppetlabs.com/~breadbox/software/ELF.txt
** using ghex2 to edit binaries directly (e.g., character array constants, numerical values)
** Intel is little-endian, meaning that the way it stores data in memory is least significant bit first, with the most significant bit "rightmost"
** When looking at hex dumps of a process image (i.e., ELF file) or disassembly, you're likely looking at the hexadecimal (base 16) representation of data values. For quick conversion, use bash's 'printf' command. For example:
     [michael@xorenduex 2011]$ printf "%x\n" 65
     41
     [michael@xorenduex 2011]$ printf "%d\n" 0x41
     65
     [michael@xorenduex 2011]$ printf "%d\n" 41
     41
     [michael@xorenduex 2011]$ printf "%x\n" 0x41
     41
     [michael@xorenduex 2011]$ printf "%x\n" 65
     41
     [michael@xorenduex 2011]$ 

** Practical warning: Typing commands repeatedly at the command line can introduce errors (such as using the wrong file names, wrong files, etc.). To reduce your workload, consider writing a Makefile and using 'make'
*'''Readings for Wednesday'''
** On vulnerability disclosure: http://seclists.org/dailydave/2010/q2/58 
** CERT's stance: http://www.cert.org/kb/vul_disclosure.html
** http://seclists.org/bugtraq/1996/May/0
** read this thread: http://seclists.org/fulldisclosure/2002/Jul/7
** https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
** http://isc.sans.edu/diary.html?storyid=6820&rss

=== 26 Jan 2011: Disclosure Discussion and ELF Toolchain ===
* Today we will formulate our ethical disclosure policy
* We will continue our investigation of program analysis with the ELF toolchain
** We focused on the system call invocation mechanism in Linux
* '''Reading for Friday'''
** x86 Function Calling Conventions: http://www.unixwiz.net/techtips/win32-callconv-asm.html
** an (old) example vulnerability and sample exploit in libpng: http://scary.beasts.org/security/CESA-2004-001.txt

=== 28 Jan 2011: Shellcode Disassembly ===
* In this class, we will discuss tools and techniques for examining shellcode. Shellcode is essentially a self-contained assembly program (like the one we have been working with). By convention, the term "shellcode" typically indicates some nefarious purpose, but shellcode is really just a small, self-contained program that depends only on the smallest set of OS and library functionality it can get away with. Along the way, we will discuss:
** the udcli tool
** calling conventions for functions vs. system calls
** write simple system call shellcode
** analyze a shellcode example
* Class Activities [[Courses/Computer Science/CPSC 601.29.ISSA/20110128CodeSession]]
** wrote a simple ASM file for writing "hello" to stdout via write(2)
*** noticed problem (i.e., SIGSEGV) with storing a low address (i.e., 65) into ebx
*** noticed problem (i.e., SIGSEGV) with not calling _exit()
*** used strace to trace the a.out to get info about where it failed
*** introduced a simple Makefile
** analyzed a shellcode example from http://www.shell-storm.org/shellcode/files/shellcode-606.php
** use udcli for disassembly (nasm also comes with a tool for this, ndisasm)
** hand-execute assembly listing by simulating CPU and keeping track of registers and stack
** patch shellcode
** manage to workaround non-executable stack with execstack -s
** use chown and chmod to setuid (chmod 4777 or 2777) on the fixed binary to ensure -p is used to proper effect
* '''Reading for Wednesday'''
** Intel Software Developers Manual, Volume 3A: System Programming Guide, Part 1
*** Sections 2.1, 2.2, 2.3, 2.4, 2.5 and 2.7

=== 2 Feb 2011: Hardware Support for Protection ===
* system operation modes
* memory management registers and system control registers
* nx bit, paging, segmentation, rings, RPL/CPL/DPL
* '''Class Notes'''
** VDSO definition: http://kernelnewbies.org/KernelGlossary#V
** Linux-gate vdso insight: http://www.trilithium.com/johan/2005/08/linux-gate/
** SYSENTER/SYSEXIT trivia: http://lkml.org/lkml/2002/12/18/218
* '''Slides''' (TBP)
* '''Readings for Friday'''
** Intel Software Developers Manual, Volume 3A: System Programming Guide, Part 1
*** these readings will re-enforce what we discuss in class
*** Chapter 3
*** Chapter 5

=== 4 Feb 2011: Trapping, Interrupt and Exception Handling ===
* We will generally discuss how different types of trapping are done at runtime at various levels of the system, with a focus on the x86 hardware support for this activity. 
* In class, we discussed this material:
** Section 6.1 (Interrupt and Exception Overview)
** Section 6.2 (Exception and Interrupt Vectors)
** Section 6.10 (Interrupt Descriptor Table (IDT))
** Section 6.11 IDT Descriptors
** Figure 2-1 (specifically, the IDTR+IDT use)
** Section 2.7 (System Instruction Summary)
** Table 2-2
* In class, we undertook the following exercises:
** understanding the Red Pill at http://invisiblethings.org/papers/redpill.html
*** requires execstack -s
*** patches the address of the destination bytes for sidt instruction at runtime
*** reports "in VM" if first byte (Most Significant Byte) of IDT base address is > 0xd0
*** discussed why this heuristic may fail six years later
** executed the 'nopill' linked from that URL as well
** tried to execute redpill on Mac OS X
** hit dearth of execstack
** attempt to write redpill in x86 assembly for 64-bit Mac with 2 cores
** http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/000-Introduction/introduction.html
** ran the resulting binary in gdb
* Potential Research Project: [[Virtual Machine Fingerprinting]]
* '''Code From Today''': [[Courses/Computer Science/CPSC 601.29.ISSA/20110204CodeSession]]
* '''References'''
** http://wiki.osdev.org/Interrupt_Descriptor_Table
** http://www.logix.cz/michal/doc/i386/chp09-00.htm
** http://ece.wpi.edu/~wrm/Courses/EE3803/Labs/roehrl.html
**http://wiki.osdev.org/GDT_Tutorial
* '''Readings for Wednesday'''
** Intel Software Developers Manual, Volume 3A: System Programming Guide, Part 1 
*** Chapter 6, Interrupt and Exception Handling
*** Chapter 16, Sections 16.1, 16.2, and 16.3
*** "Handling the IDT for Fun and Profit" http://www.phrack.com/issues.html?issue=59&id=4&mode=txt
*** "Mistifying the debugger" http://www.phrack.com/issues.html?issue=65&id=8&mode=txt

=== 9 Feb 2011: Program Supervision 1: Basic Mechanisms ===
* We will examine various primitives like ptrace(2), LSM, and library interception. We will particularly look at how ptrace(2) is implemented and can be used by one process to trace another.
* '''Notes'''
** We looked at the manual page for ptrace to understand the variety of services/request types it offers and understand some of the constraints governing its behavior
** We examined a number of places in the kernel source code dealing with the implementation of ptrace
** we first started out by understanding how the system call handling mechanism is actually coded in the kernel
** we also looked up the task_struct definition in the kernel's code and reviewed the data members of this structure relevant to ptrace
** we looked up ptrace's system call number and the definition of its prototype
** we saw how the kernel defines macros for handling different system calls with different numbers of arguments
** we understood that the implementation of ptrace has two logical parts: the general abstract part and the architecturally-dependent part, as reflected by the ptrace implementation and header files in different sections of the kernel source tree
** we looked closely at the implementation of the "highest" layer of ptrace's implementation: the actual entry into the sys_ptrace() function
** After diving into shallow waters in the kernel, we started to look at this topic from the user-level side
* '''Links'''
** These links point to various places in the Linux kernel source code dealing with ptrace.
*** The ptrace API: http://lxr.linux.no/#linux+v2.6.37/include/linux/ptrace.h (defines function prototypes for internal kernel service routines related to ptrace and "types" for ptrace requests)
*** The platform-specific ptrace API: http://lxr.linux.no/#linux+v2.6.37/arch/x86/include/asm/ptrace.h
*** The architecture-specific ABI: http://lxr.linux.no/#linux+v2.6.37/arch/x86/include/asm/ptrace-abi.h
*** Definition of sys_ptrace system call function signature: http://lxr.linux.no/#linux+v2.6.37/include/linux/syscalls.h#L704
*** enumeration of sys_ptrace in the system call list (number 26): http://lxr.linux.no/#linux+v2.6.37/arch/x86/kernel/syscall_table_32.S#L28
*** Definition of Linux "task_struct", the Process Control Block. Note particularly the location of ptrace-related flags and signal-related flags like 'ptrace', 'parent', 'real_parent', etc. http://lxr.linux.no/#linux+v2.6.37/include/linux/sched.h#L1182
*** The "highest" layer of ptrace's implementation dealing with finding the process to trace and attaching: http://lxr.linux.no/#linux+v2.6.37/kernel/ptrace.c#L697  (note the use of the SYSCALL_DEFINE4 macro)
*** See definition of the SYSCALL_DEFINE macros: http://lxr.linux.no/#linux+v2.6.37/include/linux/syscalls.h#L188
*** The part of ptrace's implementation dealing with architecturally-specific requests: http://lxr.linux.no/#linux+v2.6.37/arch/x86/kernel/ptrace.c#L804
* '''Exercises'''
** Can program A ptrace program B which ptraces program A?
** Can program A ptrace program B which is ptracing program C?
** Try to write a ptrace-based program that outputs all the return values (i.e., the value of eax) after a return from each function (i.e., after a RET instruction is executed).
* '''Reading for Friday'''
** x86 runtime process manipulation http://www.hick.org/code/skape/papers/needle.txt
** Chi-Keung Luk, Robert Cohn, Robert Muth, Harish Patil, Artur Klauser, Geoff Lowney, Steven Wallace, Vijay Janapa Reddi, Kim Hazelwood. "Pin: Building Customized Program Analysis Tools with Dynamic Instrumentation," Programming Language Design and Implementation (PLDI), Chicago, IL, June 2005, pp. 190-200 http://doi.acm.org/10.1145/1065010.1065034

=== 11 Feb 2011: Program Supervision 2: Using ptrace ===
* '''Notes'''
** We discussed the big picture of how to develop intuition for the "right" level or approach for instrumenting and extracting data about a program or process; while you can create a construct at many different system levels to extract data from another level of the system, you have to consider performance cost, available mechanisms, ease of implementation, etc.
** We looked at the implementation of a ptrace(2)-based utility for printing out system call information
* '''Code'''
** see the code at [[Courses/Computer Science/CPSC 601.29.ISSA/20110211CodeSession]]
* '''Readings'''
** None, do your flaw reports and lit reviews

=== 16 Feb 2011: Program Supervision 3: From the Kernel Up ===
* Here we will look at how to modify the kernel source directly. While we will focus on porting Mac OS X's PTRACE_DENY_ATTACH request to Linux, many of the lessons about how to touch the kernel, recompile, and redeploy extend directly to other modifications you might wish to make to the kernel to instrument, intercept, or observe processes. Note, however, that the kernel is seldom the ''best'' place to do this kind of observation. Sometimes (like in a rootkit case) it is the only environment you can depend on (as a rootkit author), but in most benign examples, it is better to:
** implement a user-level process for extracting the data
** define a psuedo device for extracting information from the kernel
** compose existing kernel interfaces or communicate with them (e.g., /proc)
** employ a Loadable Kernel Module if you absolutely must have code executing in the kernel context
Generally, you want to avoid adding extra code to the kernel, since your code might contain bugs and errors and unnecessarily complicate the kernel (or interfere with performance, since you may use locks and interact with other kernel components like the file system, disk scheduler, memory allocator, loader, or process scheduler).
* '''Code'''
** To be posted after class.
* '''Readings'''
** None, do the vuln reports and lit review, or go back and re-read some of the other references.

=== 18 Feb 2011: Program Supervision 4: Frameworks ===
* We will examine how various supervision frameworks are implemented and organized, and what services they provide above and beyond the typical system inspection primitives like the x86 INT instruction and the OS ptrace(2) facility.
* '''Notes'''
* '''Links'''
** GDB: [http://www.gnu.org/software/gdb/ download GDB] [http://sourceware.org/gdb/download/onlinedocs/gdb.html docs]
** Pin: http://www.pintool.org/
** Valgrind: http://www.valgrind.org/
** DynamoRio: http://dynamorio.org/
** Ollydbg http://www.ollydbg.de/
** Immunity Debugger http://www.immunityinc.com/products-immdbg.shtml
** IDAPro http://www.hex-rays.com/idapro/
** DTrace: http://www.oracle.com/technetwork/systems/dtrace/dtrace/index.html
** SystemTap / Kprobes: http://sourceware.org/systemtap/kprobes/
** Linux LKM HOWTO: http://tldp.org/HOWTO/Module-HOWTO/
* '''Code'''
** for code, please see [[Courses/Computer Science/CPSC 601.29.ISSA/20110218CodeSession]]
* '''Readings'''
** None; use this time to do your literature review

=== 23 Feb 2011: Reading Week, no lecture ===

=== 25 Feb 2011: Reading Week, no lecture ===

=== 2 March 2011: Midterm Exam ===

In class, open book, open note, open web, open computer. Individual.

You have an hour and fifteen minutes to email me the answers to the four questions.

The questions will focus on activities involved in the analysis of binaries.

=== 4 March 2011: Basic Countermeasures (held 7 March) ===
* Topics: libesafe, libverify, non-executable stack, W XOR X, Stack Canaries, Address space randomization, 
* Notes: We discussed the following resources:
** libsafe/libverify paper: "Transparent Runtime Defense Against Stack Smashing Attacks" http://www.usenix.org/event/usenix2000/general/baratloo.html
** http://www.usenix.org/publications/library/proceedings/sec98/full_papers/cowan/cowan.pdf "StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks" 
** OpenBSD slides: http://www.openbsd.org/papers/ven05-deraadt/ ('''you should read these''')
** "On the Effectiveness of Address Space Randomization": http://cseweb.ucsd.edu/~hovav/papers/sppgmb04.html
** Propolice Website: http://www.trl.ibm.com/projects/security/ssp/ (see particularly: http://www.trl.ibm.com/projects/security/ssp/node4.html )
** Your machine likely has a number of these in place already, and performing basic exploit research to understand the basic concepts (e.g., those presented in "Smashing the Stack for Fun and Profit" http://www.phrack.com/issues.html?issue=49&id=14&mode=txt ) requires you to turn them off to remove some complexity. This includes (but isn't limited to:
*** compiling programs with fno-stack-protector
*** turning off ASLR: as root, `echo 0 > /proc/sys/kernel/randomize_va_space'
*** marking executables as needing executable data areas: `execstack -s a.out'
* Links
** "Return Oriented Rootkits" by Hund, Holz, and Freiling: http://www.usenix.org/events/sec09/tech/full_papers/hund.pdf
* '''Code'''
** [[Courses/Computer Science/CPSC 601.29.ISSA/20110307CodeSession]]

=== 9 March 2011 (Actual 11 March): Advanced Countermeasures ===
* Topics: tainted dataflow analysis, Artificial diversity, control flow integrity
* '''Notes'''
**Class Management
***midterm answers & discussion
***turning of basic countermeasures (see notes from last time)
***demo an attack (e.g., libpng via gdb, or even a simple strcpy with all protections turned off)
**Artificial diversity
***n version programming
***anomaly detection based on system call sequences: "A Sense of Self for Unix Processes" Somayaji et al.
**** asynchronous system calls
**** convergence of a profile & calibration
**** mimicry attacks
**** looking at arguments, not just syscall sequences (UCSB work)
***ASLR (last time)
***Instruction Set Randomization (Barrantes et al., Kc et al., CCS 2003)
****mysql randomization, postgresql randomization
*** program reproduction by Somayaji et al.
**Tainted Dataflow Analysis
***TaintCheck (CMU)
***mark sources of input (i.e., from system calls such as read(2) and recv(2)) with a tag, propagate tag with each assembly instruction
***attack detection conditions
**** tainted data enters the contents of EIP
**** EIP points to an address containing tainted data
**** tainted data enters a system call argument, such as a parameter to execve(2)
**Control Flow Integrity:
***model control flow graph of an application statically; new injected control flow paths should not deviate from this static "complete" model; CFI paper
***XFI: software guards
**Advanced Topics: Signature Generation, Recovery
***STEM
***FLIPS, Shadow Honeypots, DIRA
***Vigilante
***VSEF: Vulnerability Specific Execution Filters
***Application Communities
***ShieldGen
***Bouncer
***Rx: execute through errors; see bugs as allergens, slightly change the environment and re-execute
***ASSURE: model control flow, recover to a "safe" state
***SEAD: Speculative Execution for Automated Defense: have an execution monitor that interprets "repair policy" (basically an after-production exeception handling mechanism) when a code injection attack is detected
* http://technet.microsoft.com/en-us/security/dd285253.aspx (Mitigations by Matt Miller)
* '''Code'''
** We wrote a small piece of code to gather data on the value of ESP (position of stack in a randomized (i.e., ASLR environment) or non-randomized environment.

 #include <stdio.h>
 int main()
 {
   int* x = 0;
   int y = 0xDEADBEEF;
   x = &y;
   fprintf(stdout, "%u\n", ((unsigned int)x));
   return ((int)x);
 }

This produces a distribution of values showing limited (max 3 in our experiment) reuse of the same stack state. Note that the return of x from main is truncated by the shell to a short int. We wrapped the binary in a bash shell script:

 #!/bin/bash
 for ((;;))
 do
       ./a.out >> newstack.dat
 done

and then passed newstack.dat through a chain of commands, first sorting -n the output, then passing to uniq -c, then awk to print $2 then $1, then sorting -n again. We directed that final output to a file newstack.sorted and plotted it with gnuplot (plot 'newstack.sorted' with impulses).

Turning ASLR off (via `echo '0' > /proc/sys/kernel/randomize_va_space produced a file with the same value (322122588).

=== 11 March 2011 (Actual 14 March): Debugging Session of Basic Code Injection ===
* Topics: We will use gdb to look at a simple strcpy-based injection. The idea was to shut off all protections (execstack, turn off ASLR, turn off stack protector), write a small program that uses strcpy(3) unsafely:

http://pages.cpsc.ucalgary.ca/~locasto/teaching/2011/ISSA/code/scopy.c

 #include <stdio.h>
 #include <string.h>
 int do_work(char* src){
   char dst[10];
   strcpy(dst, src);
   return 0;
 }
 int main(int argc, char* argv[]){
   if(2==argc){
     do_work(argv[1]);    
   }else{
     fprintf(stdout, "./scopy [arg]\n");
     return -1;
   }
   return 0;
 }

and then proceed to look at the stack using GDB:

http://pages.cpsc.ucalgary.ca/~locasto/teaching/2011/ISSA/code/session.txt

* Notes:
* Links

=== 16 March 2011: Analysis of a Real (but old) Vulnerability ===
* Topics: the point of this lecture is to provide a hands-on assessment of an old stack-based buffer overflow vulnerability and the resulting exploit. This takes the previous class and cranks it up a notch: the vuln is in real, widely used software, and we get a richer address space than just a simple program copying a string from argv[1]
* Notes: In this class, we looked at a wealth of information in both the source code (at the src-level definition of various functions) and at the assembly level. We first observed how rpng-x reacted when fed the proof-of-concept test case to exercise the vulnerability. We observed some output error messages and then a segfault. We started rpng-x in gdb and began to place breakpoints from the png_handle_tRNS() function in the `pngrutil.c' file. We placed breakpoints at different related functions (e.g., png_crc_finish, png_read_data, png_default_read_data) and looked at them both at the source level as well as disassembly within gdb. We were able to modify the PoC exploit to include shellcode that spawned a shell once we got the return address correct (via stack examination of where the NOP sled landed on the stack). The key problem seemed to be that the length of a fixed-sized local buffer (256 declared bytes) -- and specifically the amount of space allocated on the stack (300 bytes) was smaller than the 512 bytes of data that fread(3) ultimately stuffs into that fixed-sized local buffer.
* '''Code Session'''
** To be posted
* '''Links'''
** http://scary.beasts.org/security/CESA-2004-001.txt
** http://scary.beasts.org/misc/pngtest_bad.png
** http://www.libpng.org/pub/png/libpng.html
** http://www.kb.cert.org/vuls/id/388984
* '''Readings'''
** "On the Infeasibility of Modeling Polymorphic Shellcode": http://pages.cpsc.ucalgary.ca/~locasto/papers/model-polymorphic-decoders.pdf

=== 18 March 2011: Heap-based Overwrites of Function Pointers ===
* Topics: observing how to overwrite heap-resident data structures, with some insight into overwriting heap management structures themselves
* '''Code'''
* '''Readings'''
** page 150 in "Hacking: The Art of Exploitation"
** "Once Upon a free()": http://phrack.org/issues.html?issue=57&id=9&mode=txt
** "Vudo - An object superstitiously believed to embody magical powers" http://phrack.org/issues.html?issue=57&id=8&mode=txt
** "MALLOC DES-MALEFICARUM": http://phrack.org/issues.html?issue=66&id=10&mode=txt
** See Patrick's collection of papers: http://wiki.ucalgary.ca/page/Protecting_Against_Heap-Based_Buffer_Overflows

=== 23 March 2011: Counter-Countermeasures 1 (rescheduled to 25 March, 3pm) ===
* Topics: Polymorphism, Metamorphism, return-to-libc, bounce off linux gate, ROP. 
* Notes: Today we'll play with a piece of polymorphic shellcode (cd eject).
* '''Readings'''
** These are prep for english shellcode topic...
** From the textbook: page 366 to 376
** From academia: http://www.cs.jhu.edu/~sam/ccs243-mason.pdf
** From the hacker community: 
*** "Writing ia32 alphanumeric shellcodes" http://phrack.org/issues.html?issue=57&id=15&mode=txt
*** http://www.blackhat.com/html/bh-usa-05/bh-usa-05-speakers.html (grep Shakespearean Shellcode)
*** http://media.blackhat.com/bh-usa-05/audio/2005_BlackHat_Vegas-V31-D_Barrall-Shakespearean_Shellcode.mp3
*** http://mirror.fpux.com/HackerCons/Blackhat%202005/CD/BH_US_05_BARRALL.PDF

=== 25 March 2011: Counter-Countermeasures 2 ===
* Topics: English Shellcode. Today we'll play with constructing valid shellcode that maps to printable ASCII characters.
* '''Readings'''
** Bypassing ASLR: http://www.phrack.org/issues.html?issue=59&id=9&mode=txt
** Non-control data attacks: http://research.microsoft.com/en-us/um/people/shuochen/papers/usenix05data_attack.pdf

=== 30 March 2011: Reverse Engineering Protocols and File Formats ===
* '''Notes''' Today we'll discuss non-control data attacks (can be thought of as a counter-countermeasure). We will also discuss some approaches for reverse-engineering file formats and network protocols.
** PCAP file format: http://wiki.wireshark.org/Development/LibpcapFileFormat
** PCAP file format documentation: http://www.manpagez.com/man/5/pcap-savefile/
** WMF: http://msdn.microsoft.com/en-us/library/cc215212.aspx
** compiler-induced security bugs: https://www.securecoding.cert.org/confluence/download/attachments/26017980/SD+West+Dangerous+Optimizations.pdf?version=1
** error in linux kernel induced by compiler: http://isc.sans.edu/diary.html?storyid=6820&rss with technical analysis: http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html
* '''Links/Related Work''' note: Weidong Cui's work figures heavily in the academic space here
** "Protocol-Independent Adaptive Replay of Application Dialog" http://research.microsoft.com/en-us/um/people/wdcui/papers/roleplayer-ndss06.pdf
** "Tupni: Automatic Reverse Engineering of Input Formats" http://research.microsoft.com/en-us/um/people/wdcui/papers/tupni-ccs08.pdf
** "Replayer: Automatic Protocol Replay by Binary Analysis" Newsome, Brumley, Franklin, and Song. (CCS 2006)
** "Discoverer: Automatic Protocol Reverse Engineering from Network Traces" http://research.microsoft.com/en-us/um/people/wdcui/papers/discoverer-security07.pdf
** "Automatic Network Protocol Analysis" Gilbert Wondracek, Christopher Kruegel, Engin Kirda - Technical University Vienna; Paolo Milani – Scuola Superiore S. Anna, Italy (NDSS 2008)
** "Automatic Protocol Format Reverse Engineering through Context-Aware Monitored Execution" Zhiqiang Lin, Dongyan Xu, Xiangyu Zhang - Purdue University; Xuxian Jiang - George Mason University (NDSS 2008)

=== 1 April 2011: Measuring Security Code ===
* Topic: this will be a hands-on class where we will attempt to measure various security primitives and learn something about their organization.
* [[Cost of Information Security]]

=== 6 April 2011: Intrusion Analysis: Classic Examples and the Invention of Honeypots ===
* '''Topic''': Today we'll discuss some classic work in intrusion incident analysis
* '''Notes''' Stories about post-mortem analysis of such incidents are rare. Here are a few links and pointers:
** "[http://www.wired.com/threatlevel/2009/10/walmart-hack/ Big-Box Breach: The Inside Story of Wal-Mart’s Hacker Attack]"
** Chronicle of a Server Break-In ([http://www.linux-magazine.com/Online/News/Update-Fedora-Chronicle-of-a-Server-Break-in HTML], see [https://www.redhat.com/archives/fedora-announce-list/2009-March/msg00010.html link to Paul’s actual postmortem])
** Abe Singer. "Tempting Fate," ;login:, Volumn 30, #1, Usenix Association, November 2005. (grab a copy of ;login)
** Eugene H. Spafford. [http://spaf.cerias.purdue.edu/tech-reps/823.pdf The Internet Worm Program: An Analysis] (PDF)
** Cliff Stoll. "[http://vx.netlux.org/lib/mcs00.html The Cuckoo’s Egg]" (HTML)
** Bill Cheswick. "[http://cheswick.com/ches/papers/berferd.pdf An Evening With Berferd In Which a Cracker is Lured, Endured, and Studied]" (PDF)
* '''News'''
** COMODO
*** http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
*** http://blogs.comodo.com/it-security/data-security/the-changing-threat-model/
*** http://arstechnica.com/security/news/2011/03/how-the-comodo-certificate-fraud-calls-ca-trust-into-question.ars
** RSA
*** http://blogs.rsa.com/rivner/anatomy-of-an-attack/
** Epsilon
*** http://www.cbc.ca/news/business/story/2011/04/05/business-data-breach.html?ref=rss
*** http://www.thestreet.com/story/11070689/1/retailers-victims-of-e-mail-hackers.html?CM_VEN=AD|TWR|JC
*** Don't make me laugh: http://www.geeksquad.com/do-it-yourself/tech-tip/six-steps-to-keeping-your-data-safe.aspx
** NASA
*** http://www.boingboing.net/2011/04/02/nasa-cybersecurity-r.html
* '''Links''' Some sites collect data breach incidents, and Verizon's yearly data breach report is always interesting
** http://www.privacyrights.org/
** http://newscenter.verizon.com/press-releases/verizon/2010/2010-data-breach-report-from.html
** http://twitter.com/Privacy_Breach (BC-centric; doesn't seem terribly popular)
** https://twitter.com/#!/datalossdb (see datalossdb.org)

=== 8 April 2011: Intrusion Recovery: Responding and Cleanup ===
* '''Topic''': Today we'll discuss my LISA 2009 paper and the incidents therein. We'll look at the residue of one of the intrusions.
* '''Readings'''
** http://pages.cpsc.ucalgary.ca/~locasto/papers/boulders.pdf
** My slides: http://www.usenix.org/event/lisa09/tech/slides/locasto.pdf

=== 13 April 2011: Towards a formal theory of computer insecurity: a language-theoretic approach ===
* Topic: we will watch a video talk by Len Sassaman and Meredith L. Patterson related to their recent ph-neutral talk (link below) 
** ISTS Seminar on YouTube: http://www.youtube.com/watch?v=AqZNebWoqnc&feature=player_embedded
** "Exploiting Computational Slack in Protocol Grammars" http://ph-neutral.darklab.org/previous/0x7da/talks/grammars.html

=== 15 April 2011: Guest Lecture on Quality of Digital Evidence (Sergey Bratus) ===
* Topic: Sergey will discuss the practical reliability, security, and quality issues involved with creating and assessing digital evidence. He will use a case study to examine these issues. He will also consider some of the legal and ethical issues involved in letting our legal systems use machine-produced evidence as the basis of a legal assault on individuals.
* '''Notes/Readings''':
** http://recordingindustryvspeople.blogspot.com/2009/06/umg-recordings-v-mavis-roy-case-settled.html
** http://beckermanlegal.com/pdf/?file=/Lawyer_Copyright_Internet_Law/umg_roy_090530ExpertWitnessReport.pdf
** Slashdot coverage: http://yro.slashdot.org/story/09/06/20/1535220/Analysis-of-MediaSentry-Wins-Music-Download-Suit?from=rss

== Systems Infosec Theme Areas (Examples for Essay/LitReview Topics) ==

The recent literature has many themes. The following are but a taste.

=== Example Themes ===
* Automated Diversity: Instruction Set Randomization, Address Space Randomization
** http://www.cs.unm.edu/~immsec/publications/hotos-97.pdf "Building Diverse Computer Systems"
** http://www.cs.unm.edu/~gbarrant/p315-barrantes.pdf "Randomized Instruction Set Emulation to Disrupt Binary Code Injection Attacks"
** http://www1.cs.columbia.edu/~angelos/Papers/instructionrandomization.pdf "Countering Code-Injection Attacks with Instruction-Set Randomization"
** http://www.stanford.edu/~blp/papers/asrandom.pdf "On the Effectiveness of Address-Space Randomization"
** http://www.phrack.com/issues.html?issue=59&id=9&mode=txt "Bypassing PaX ASLR protection"
* Return-Oriented Programming
** http://www.phrack.com/issues.html?issue=58&id=4&mode=txt "The advanced return-into-lib(c) exploits: PaX Case Study"
** http://cseweb.ucsd.edu/~hovav/dist/geometry.pdf "The Geometry of Innocent Flesh on the Bone"
** http://cseweb.ucsd.edu/~hovav/talks/blackhat08.html "Return-Oriented Programming: Exploits Without Code Injection" (BlackHat08)
* Buffer Overflow Protection
** http://www.ida.liu.se/~johwi/research_publications/paper_ndss2003_john_wilander.pdf "A Comparison of Publicly Available Tools for Dynamic Buffer Overflow Prevention
** http://www.usenix.org/publications/library/proceedings/sec98/full_papers/cowan/cowan.pdf "StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks"
** http://www.usenix.org/events/sec03/tech/full_papers/cowan/cowan.pdf PointGuard(TM): Protecting Pointers From Buffer Overflow Vulnerabilities
** http://www.phrack.org/issues.html?issue=56&id=5&mode=txt "Bypassing StackGuard and StackShield"
** http://uninformed.org/?v=2&a=4&t=txt "Bypassing Windows Hardware-enforced Data Execution Prevention"

Background reading:
* http://www.angelfire.com/sk/stackshield/info.html StackShield
* http://www.trl.ibm.com/projects/security/ssp/ Propolice (Useful as a sensor reporting to syslog)
* http://support.microsoft.com/kb/875352 Microsoft DEP
* http://www.openbsd.org/papers/ven05-deraadt/index.html OpenBSD W^X

=== Conference Proceedings / Programs ===

USENIX Security: http://www.usenix.org/events/sec10/index.html

ACM CCS: http://www.sigsac.org/ccs.html

NDSS: http://www.isoc.org/isoc/conferences/ndss/

Oakland: http://www.ieee-security.org/TC/SP-Index.html

== Literature Reviews ==
Post links to your literature reviews (PDF preferred) here or create a new wiki page for it.

*[http://people.ucalgary.ca/~cjjarabe/papers/jarabek_cloud_security.pdf A Review of Cloud Computing Security: Virtualization, Side-Channel Attacks, and Management]
*[[Protecting Against Heap-Based Buffer Overflows]]
*[[Social Engineering]]

== Flaw Reports ==
Post links to your flaw reports (PDFs, URLs) here, or create new wiki pages describing each.

[http://www.ucalgary.ca/~cjjarabe/papers/jarabek_bug_summary.pdf Flaw report: Kimai]

[http://pages.cpsc.ucalgary.ca/~jdgallag/GoAway/Bug.pdf Megavideo and Leksah: Ethical Brief Reports]
[http://pages.cpsc.ucalgary.ca/~jdgallag/GoAway/GHCBug.pdf GHC: In Depth Analysis]
[http://pages.cpsc.ucalgary.ca/~jdgallag/GoAway/BugMV.pdf Megavideo]


[https://webdisk.ucalgary.ca/~jungles/public/BugReportATutor.pdf ATutor Multiple Flaw Report]

[https://webdisk.ucalgary.ca/~jungles/public/BugReportPDFreader.pdf Cad-Kas PDFreader Flaw Report]

[https://webdisk.ucalgary.ca/~sgcartwr/public/vulns/Vuln1_public.pdf PHFTP XSS Report]

[https://webdisk.ucalgary.ca/~sgcartwr/public/vulns/Vuln2v3_public.pdf TEMS XSS Report]

We will have a discussion of vulnerability disclosure policies and approaches to vulnerability disclosure sometime in the next couple of weeks. I am comfortable with posting your analysis on the public wiki (i.e., here) if you have submitted the issue to the vendor and had some acknowledgment or communication with them.

Your flaw reports will be due by the end of the semester, but I encourage you to get them in before then.

=== Sites To Bootstrap Your Thinking ===
* http://httpd.apache.org/security_report.html
* http://www.mozilla.org/security/known-vulnerabilities/firefox36.html#firefox3.6.13
* http://samba.org/samba/history/security.html

== Ethical Disclosure Policy ==

Our class policy is the following:

The value of this exercise for the student is threefold. First, the student puts into practice the analysis tools and techniques covered in the course. Second, the students nurtures their "security mindset" by examining code with the intent to violate its expectations about correct execution. Finally, students will gain some practical experience with the ethical and practical considerations involved in the disclosure of real-life flaws.

Users and vendors have a right to be informed of potential bugs, flaws, and vulnerabilities. Our first principle is to be as precise and accurate as possible with the information we develop. Speculation should be clearly separated from the facts of the flaw report description. We will assemble information about the code flaw itself and the conditions under which it can be exercised. We will make a good faith effort to contact vendors to report this information to them ahead of any public disclosure. This contact may include personal email where the vendor is a single person responsible for maintaining the software, but we will seek to report the flaw via the vendor-preferred channels (such as a special security mailing list for the project or product or a bugzilla report). After receiving an acknowlegement from the vendor, we may choose to post a brief, abstract description of the flaw on this wiki in terms that generally mimic CERT advisories. In any case, the full report will be sent privately to the instructor. We have no obligation to offer a fix or support for the bug.

=== Raw Notes from Class Discussion ===

There are several adjectives that we might modify the term "disclosure" with, e.g.,:

*Disclosure
*Full Disclosure
*Partial Disclosure
*Ethical Disclosure
*Unethical Disclosure
*Responsible Disclosure
*Irresponsible disclosure

but it is worth asking the question whether there is any such thing as "ethical" disclosure? 

The complexity of this decision (who to inform, when to tell them, what to tell them, how to follow up or support your announcement) can potentially offend some stakeholder or fall out of line with ''their'' ethical expectations or frame of reference.

There is also the issue of the legal ramifications of disclosure, ranging from violating a software license agreement to violating local, state, or federal statute.

Key question: Who do you tell, when?

*what about your employer?
*severity of a flaw
*but: big hole still exists
*how do you convince vendor?
**your credibility, employer, background, track record
**how hard it is to actually exploit
*vendor response, nature of the vendor
*users (how?) specific system  or bug list
*is timeline a consideration?
**difficulty of deploying "fix" or workaround
**time reporting window in terms of patch cycles
*should we propose solution or work with vendor (potential pitfall: you may promise a fix you can't deliver b/c you didn't completely understand the vuln)
*do you have culpability for the quality of your report? generality?
*compensation?

===== Principles =====

* consensus: we should post, but only after disclosure to vendor
* level of detail on wiki: CERT or secunia advisory
* level of detail to prof: full disclosure
* level of detail to vendor: full disclosure
* level of detail to public: full disclosure to public IFF vendor has patched issue ?
* should give vendor a window of opportunity
** standard bug reporting (companies)
** bugzilla or mailing list for security issues
** severity, user base, exact time window, consequence
* where does obligation end?

== Suggested Projects ==

These are not class assignments, but interesting research or development ideas that occur during class. If one interests you, talk to me about setting up a project.

*interesting experiment: rewrite a selection of security policies and models in E-Prime and survey ~25 security professionals for their impression of clarity, precision, correctness, etc.
*augment ghex2 (or your favorite hex editor) to automatically group/tag similar or equal groups of bytes and replace the grouping with the tag name
*comparative analysis of gdb, IDAPro, and Immunity Debugger
*Use scapy to pass network data to udcli, use "abstract payload execution" to determine whether these bytes really are code; compare with NEMU

== Other Resources ==
*Philosophy
** http://stallman.org/articles/on-hacking.html
** http://www.cs.dartmouth.edu/~sws/pubs/pretending.pdf
**the Hacker Curriculum web site: [http://www.hackercurriculum.org/]
**U of C wiki: [[Information Security Reading List]]
*Fun and Puzzles
**[http://tuts4you.com/ Tuts4You](Tutorials for reverse engineering, disassembling and unpacking code)
**[http://www.exploit-db.com/ Exploit-DB] (Exploit Database)
**[http://www.owasp.org/ OSWAP] (Webscarab will be handy to those testing web-services)
**[http://www.overthewire.org OverTheWire] (Hacking Games - former Pulltheplug (Vortex) )
**[http://crackmes.de/ Crackmes] (practice "cracking" specific protection or puzzles)
** http://www.youtube.com/watch?v=5CWrzVJYLWw
*Reference Info
**http://www.uninformed.org/
**http://pdos.csail.mit.edu/6.828/2005/readings/i386/c06.htm (Chapter on x86 Protection)
**http://asm.sourceforge.net/
**http://checklists.nist.gov
**http://iase.disa.mil/stigs
**Mach Binary Format: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html#//apple_ref/doc/uid/TP40000895
*Misc.
**http://www.redhat.com/mirrors/LDP/HOWTO/Module-HOWTO/copyright.html
**Required reading for security/reliability professionals: [http://sunnyday.mit.edu/papers/therac.pdf Therac-25 Incident]
*Tools and Libraries
**Fuzzing With Spike: http://resources.infosecinstitute.com/intro-to-fuzzing/
**Automated Fuzzing: http://resources.infosecinstitute.com/fuzzer-automation-with-spike/
**http://www.nongnu.org/libunwind/
**010 Editor http://www.sweetscape.com/
*Security-related Mailing lists (feel free to add to this list)
** http://www.schneier.com/crypto-gram.html
** hash-forum [at] nist.gov
** http://wiki.laptop.org/go/Security
** https://www1.ietf.org/mailman/listinfo/ipsec
** http://www.apache.org/security/
*RSS&Atom feeds (non-academic)
** http://www.theregister.co.uk/security/headlines.atom
** http://www.h-online.com/security/atom.xml
** http://www.offensivecomputing.net/?q=blog/feed
** http://www.securityfocus.com/rss/vulnerabilities.xml
** http://www.kb.cert.org/vuls/atomfeed?OpenView&start=1&count=30
*Magazines
** [http://hakin9.org/magazine Hakin9] (free & you can use disposable e-mail addresses for subscribing; different topics in foreign-language editions)
** [http://www.phrack.com Phrack] and [http://www.phrack.com/issues.html?issue=49&id=14&mode=txt Smashing the Stack for Fun and Profit by Aleph1]

== Information Security Conferences and Workshops ==
*USENIX Security
*Oakland
*CCS
*NDSS
*ACSAC
*RAID (Intrusion Detection specialty conference)
*SOUPS (Usable Security specialty conference)
*Eurosec
*ESORICS
*HotSec
*LEET
*NSPW
*DIMVA
*HotDep
*WPES (privacy workshop)
*WEIS (Workshop on Economics of Information Security)
*CCC 
**27C3 Conference Recordings: http://events.ccc.de/congress/2010/wiki/Conference_Recordings
**26C3 Conference Recordings: http://events.ccc.de/congress/2009/wiki/Conference_Recordings
**...
*[http://www.blackhat.com BlackHat], [http://www.defcon.org DefCon], [http://www.toorcon.org/ Toorcon], [http://www.recon.cx/ Recon], [http://www.troopers10.org TROOPERS], [http://cansecwest.com/ CanSecWest]
*...