iTrustPage: A User-Assisted Anti-Phishing Tool User helps the tool decide what is and isn't a phishing website. Current tools haven't stopped phishing: a proliferation of tools, but phishing is on the rise. Problem is auto-detection, which is subject to false negatives, just one of which puts the user at risk. Can we eliminate false -ves? SpamAssassin can be used to stop phishing. Evaluated on two corpora: one (size 1423) totally comprised of phishing email, and one (size 478) of clear email. In the default configuration, 30% false -ves. In the most aggressive, 8.7% false -ves. Default 0% false +ves, but most aggressive 15.5% false +ves. Fundamental trade-off between false +ves and -ves. Benefits of user-assistance. False +ves are unlikely and more tolerable -- if it does happen, the user is more likely to tolerate his own mistake. Can use techniques that are hard for computers but easy for people. Involve users by asking them to determine "intent": describe a page as if entering search terms. Determine whether pages "look alike" (visual similarity). Only ask a user to validate a page when he enters input on it. Then use a simple whitelist (top 500 websites by popularity) and cache previous validation decisions. Otherwise, flag a page as suspicious and rely on user-assistance. Step 1. Input key word terms that describe the site, and see if the site is one of the top ten pages returned by Google. Step 2. Here are some visual representations of the pages, and you click on the one that looks like the (potential) phishing page. If the user can't find the page on Google, he gets the opportunity to revise the search terms, or bypass the validation. Evaluated using 5184 unique installations, 2050 users with 2+ weeks of activity. Instrumented code with anonymised logs. Measure how annoying the tool is; how willing users are to help validation; and whether it prevented any phishing attacks. On first day, asks the user to validate 2% of web pages, reaches steady state areound 1.25% after 10 days. 45% of users always clicked bypass. 20% always went through validation. The rest were a mix. --- SwitchBlade: Enforcing Dynamic Personalized System Call Models 95% of vulnerabilities are remotely exploitable. Need to detect these attacks, with, ideally, total precision, no false alarms and no performance overhead. SwitchBlade makes it hard to exploit vulnerabilities undetected. Vulnerability/language independent. Has a low false alarm rate and performance overhead (similar to system call interposition). Assume attacker needs to execute system calls to exploit. The behaviour of the attacked application will deviate from normal behaviour. Model the behaviour of the application as the series of system calls it makes (an FSM). An attacker might take the system to a different state, or attempt to skip a state. Given a model of the system call behaviour, monitor application execution at runtime and look for deviations. In the learning mode, run the application with taint analysis to learn or update the system call model. Do application-level checkpoints, and switch to taint-analysis/learning mode to reexecute the code and determine if it was really an attack. If it was a false alarm, update the model and carry on. But the application could have unknown code (plugins) or an attacker could attempt to mimic the system call model. Personalisation means that the minimal model is learned for the set of features used by the user. Dynamic learning of system calls (with stack trace and a trace of dataflow for arguments). Then switch to the much faster enforcer mode. Cannot be sure that the model is complete (e.g. what if you don't execute all error handling paths?). Use fault injections the exercise the different paths. Unused features: depending on the web browser used as the client, apache uses different models (because of browser-specific hacks). Usually use enforcer mode, when a violation is detected, switch to (much slower) learning mode. Then decide whether to abort, based on replay of the last inputs and taint analysis. Mimicry of the model can be handled by inserting randomised system calls into the application, which are hard for an attacker to guest. Implemented on Linux using utrace; learner is based on Valgrind; and a network proxy for replaying HTTP requests. Need to modify application source code to use this approach (+181 lines to one file in Apache (for checkpointing and replay); no changes to modules). ghttpd required +133 lines. All other experiments work with a generic wrapper, with replay relying on app-specific checkpointing. Evaluted for Apache connection time versus native and TaintCheck. Generally not much worse than native; much better than TaintCheck (except where a lot of system calls are made, for large static files). Evaluated against 18 synthetic exploits which were all stopped by the tool. Three real-world exploits were stopped against ghttpd and two against mod_php in Apache. --- Eudaemon: A Good Spirit Affordable Zero-Day Exploit Protection for Desktop Systems Taint analysis works well but has high overhead. It tags untrusted inputs as tainted, through the execution of the program, watching where they are used in control-flow-affecting operations (call, jmp, etc.). Honeypots are heavily monitored bait hosts, which need an accurate detection mechnism. But they are slow. And they are insufficient for targeted attacks. Goal is to bring the advantages of honeypot-taint-analysis to the desktop. Will protect the actual applications and host, and cope with configuration divergence. Aim to use idle cycles to hide the overhead. Can also target the protection at the necessary applications dynamically. Machine could run a honeypot screensaver. "Hit the panic button" when you're about to do something risky. Need taint analysis for individual applications. Use a secure process emulator, which does dynamic binary rewriting/translation to apply taint analysis to unmodified binaries. Based on Argos secure system emulator, modified to run processes, and built as a shared library to be linked into the tracked application. Need to extend analysis between processes, by tracking IPC or user files. Need to be able to "possess" and "release" a process, moving it into and out of taint analysis mode dynamically (but with no visible process interruption). Use debugging interfaces which are present in major commodity OSs. No additional privileges are required to modify the execution of your own process. Secure emulator is injected into the process (LD_PRELOAD). When the Eudaemon is attached, the CPU state is copied into the secure emulator, and the process is resumed in the emulator. This can happen in the opposite direction as well. To possess: ptrace attach to the process. Then discover the libSEAL (secure emulator library) symbols, then inject some shellcode to activate the emulator (exploiting the fact that you can overwrite the first part of the ELF header). The shellcode first checks to see if the emulator is already running (by issuing a trap), then mmaps to allocate a new stack for the emulator, and finally runs the emulator, based on the current CPU state. Memory overhead is one bit per byte, with taint-tracking pages allocated only for the part of the address space that is allocated. Also have a tag-page lookup table, which has an overhead that is 1/(2^10) of the address space size. The libSEAL memory is protected using this table. Evaluated based on performance. Very good (no performance hit) on wget; 6--15x overhead on sftp, bunzip2 and konqueror. But much better than the slowdown from Argos (on which libSEAL is based). Also evaluated with microbenchmarks for switching between modes (1.290ms to switch into emulation; 2.782s to switch out of emulation (mostly due to waiting for the emulator to exit)). --- Manageable Fine-Grained Information Flow Decentralised Information Flow Control (DIFC) improves security by preventing inappropriate information flows. Inappropriate is defined by the developers. e.g. Taint social security numbers moving through a system by tainting these with their owners IDs. DIFC works, IFC has been around for a while, but hasn't seen much widespread success because it has a challenging programming model. The Asbestos web server policy runs one worker process per user, which are not allowed to send data freely but can receive data freely. A database proxy interposes on all data going into or out of the DB and is a trusted application component. The DB is isolated for security. 11 label operations are required for this policy, and must be implemented by the developers. Hard to debug, and poorly implemented policies lead to security problems and bugs. Solving these bugs leads to developers being likely to grant excessive privilege. Policy bugs are indistinguishable from attempts to break IFC -- silently drop the message. Debugging requires collection and exposure of information, but DIFC gets in the way of this. Goal is to make the programming model easier to use, program and reason about. Address policy management and debugging. Contributed a policy description language (policies as high-level rules), which can be converted into DIFC policies. Added a new kernel mechanism to provide system state management without violating the policies (e.g. debugging privilege). Abstract policy: DB can only communicate with DB Proxy. DBP proxy can communicate with anyone. Worker can receive from anyone, send only to DBP. A better policy management model enables developers to express default and explicit rules. A default policy applies at the level of the protection domain/component (i.e. send/recv any; send none/recv any; etc.). DIFC applications use specialised launchers or wrappers to initialise the policy. Can do this using the language. Asbestos uses a lightweight process abstraction to provide different worker processes per user. Policy language should support this polymorphism, and it does using a special class of dynamic executables. Parser and launcher implemented in Python. Maps to major DIFC systems (Asbestos, Hi*, Jif). Using the policy language removed 511 line long launcher/wrapper for the Asbestos web server, and removed 28 policy related operations from around the code. HiStar ClamAV (antivirus) using only 40 lines of policy description code, removing a 110-line-long wrapper. Did same for a few other systems. Label configurations can be adapted to other systems (HiStar, Flume). Debugging challenges as we require to be able to inspect the system state, which DIFC is supposed to limit. In *D*IFC, any user can create and manage private policies and protection domains. Even knowing if an attempt is made to access something leaks a bit of information. Solution is to add a debug domain which systematically models the debug privilege. On an error, the kernel generates debugging information and sends it to the relevantly-privileged processes and this carries the appropriate contamination. e.g. Alice might have a secret diary, and create a debugger that has a privilege to debug the diary. It can then declassify (appropriately) information that is tagged as being in the diary. --- Flicker: An Execution Infrastructure for TCB Minimization Trusted Computing Base: something that carries out a security sensitive task, but which includes everything that you run on top of (an application, other root applications, kernel, hardware, etc.). Flicker lets you run your sensitive code on top of a tiny shim (250 LOC) that is isolated from all the other things in the system. Use a Trusted Platform Module (TPM) to record information about the state of the platform software in the Platform Configuration Registers (PCRs). These can only be extended to create a chain of hashes, or reset under special circumstances (late launch). Late launch lets you launch a VMM under your regular operating system after the system was originally booted. SKINIT on AMD; SENTER on Intel. Performs operations atomically: resets the dynamic PCRs to 0, disables interrupts and extends a measurement of your code block into PCR 17. Then begins executing at the beginning of the memory region. Core technique: pause your operating system, late-launch the sensitive code, then resume what was running beforehand. Can be extended to attest only to the code that has been executed and its protection; also preserve state securely across invocations; and have secure communication with third parties. A kernel module is used to start the process. The sensitive code is run by the shim, after doing some measurements, and the outputs are also measured. State is scrubbed before relaunching the operating system. A sentinel value is extended into the PCRs to show the point where the shim finishes running. The attestation is much smaller (covering much less software) than if you are running on top of a whole operating system and software stack. Context switch can be implemented by using sealed storage to make sure that a rogue piece of software cannot succeed in discovering the swapped-out state. (Encrypted based on the unforgeable PCRs.) Sensitive code is linked with a Flicker library using a customised linker script. Can then interact with it via the kernel module. Shim default functionality is pretty limited. But security-sensitive functions (key generation etc.) don't usually require much library support in order to carry out their task. Some tools were developed to automatically extract the security-sensitive parts of the code. Application 1: rootkit detector. Scans through kernel memory and sends an attested version of the result back to the remote administrator. Application 2: SSH passwords, which can be kept in encrypted memory on the server. Also, an enhanced CA, (private signing key is isolated) and verifiable distributed computing. Evaluation. A context switch requires an SKINIT and TPM-based protection of application state. SKINIT takes 14ms. Unsealing application state takes over 900ms. And resealing the state takes 20ms. No-op context switch takes 939ms. Rootkit detection performance includes a 973ms TPM quote to give a 1023ms detection period. However, the quote can happen outside the Flicker session. SSH password exchange adds only 2s to a client login, but it has a big effect on the server under concurrent logins. Non-volatile storage (with PCR access control) can improve performance and gives a >10x improvement over doing unsealing. Hardware improvements can improve performance too. Late launch only when Flicker session launches, unseal only used long-term and multicore systems remaining interactive. Context switch overheads become about 0.5microsecs. Q: The kernel module chooses the shim which is used, so it can ensure that the OS protection code is used.