We present Flicker, an infrastructure for executing securitysensitive code in complete isolation while trusting as few as 250 lines of additional code. Flicker can also provide meaningful, fine-grained attestation of the code executed (as well as its inputs and outputs) to a remote party. Flicker guarantees these properties even if the BIOS, OS and DMAenabled devices are all malicious. Flicker leverages new commodity processors from AMD and Intel and does not require a new OS or VMM. We demonstrate a full implementation of Flicker on an AMD platform and describe our development environment for simplifying the construction of Flicker-enabled code.

{minwu, rcm, glittle} @ csail.mit.edu We introduce a new anti-phishing solution, the Web Wallet. The Web Wallet is a browser sidebar which users can use to submit their sensitive information online. It detects phishing attacks by determining where users intend to submit their information and suggests an alternative safe path to their intended site if the current site does not match it. It integrates security questions into the user’s workflow so that its protection cannot be ignored by the user. We conducted a user study on the Web Wallet prototype and found that the Web Wallet is a promising approach. In the study, it significantly decreased the spoof rate of typical phishing attacks from 63 % to 7%, and it effectively prevented all phishing attacks as long as it was used. A majority of the subjects successfully learned to depend on the Web Wallet to submit their login information. However, the study also found that spoofing the Web Wallet interface itself was an effective attack. Moreover, it was not easy to completely stop all subjects from typing sensitive information directly into web forms.

We present a usability study of two recent password manager

The future of digital systems is complexity, and complexity is the worst enemy of security.-- Bruce Schneier [40]. The large size and high complexity of securitysensitive applications and systems software is a primary cause for their poor testability and high vulnerability. One approach to alleviate this problem is to extract the security-sensitive parts of application and systems software, thereby reducing the size and complexity of software that needs to be trusted. At the system software level, we use the Nizza architecture which relies on a kernelized trusted computing base (TCB) and on the reuse of legacy code using trusted wrappers to minimize the size of the TCB. At the application level, we extract the security-sensitive portions of an already existing application into an AppCore. The AppCore is executed as a trusted process in the Nizza architecture while the rest of the application executes on a virtualized, untrusted legacy operating system. In three case studies of real-world applications (ecommerce transaction client, VPN gateway and digital signatures in an e-mail client), we achieved a considerable reduction in code size and complexity. In contrast to the few hundred thousand lines of current application software code running on millions of lines of systems software code, we have AppCores with tens of thousands of lines of code running on a hundred thousand lines of systems software code. We also show the performance penalty of AppCores to be modest (a few percent) compared to current software.

Abstract. In this usability study of phishing attacks and browser antiphishing defenses, 27 users each classified 12 web sites as fraudulent or legitimate. By dividing these users into three groups, our controlled study measured both the effect of extended validation certificates that appear only at legitimate sites and the effect of reading a help file about security features in Internet Explorer 7. Across all groups, we found that picturein-picture attacks showing a fake browser window were as effective as the best other phishing technique, the homograph attack. Extended validation did not help users identify either attack. Additionally, reading the help file made users more likely to classify both real and fake web sites as legitimate when the phishing warning did not appear. 1

Phishing, or web spoofing, is a growing problem: the Anti-Phishing Working Group (APWG) received almost 14,000 unique phishing reports in August 2005, a 56% jump over the number of reports in December 2004 [3]. For financial institutions, phishing is a particularly insidious problem, since trust forms the foundation for customer relationships, and phishing attacks undermine confidence in an institution. Phishing attacks succeed by exploiting a user’s inability to distinguish legitimate sites from spoofed sites. Most prior research focuses on assisting the user in making this distinction; however, users must make the right security decision every time. Unfortunately, humans are ill-suited for performing the security checks necessary for secure site identification, and a single mistake may result in a total compromise of the user’s online account. Fundamentally, users should be authenticated using information that they cannot readily reveal to malicious parties. Placing less reliance on the user during the authentication process will enhance security and eliminate many forms of fraud. We propose using a trusted device to perform mutual authentication that eliminates reliance on perfect user behavior, thwarts Man-in-the-Middle attacks after setup, and protects a user’s account even in the presence of keyloggers and most forms of spyware. We demonstrate the practicality of our system with a prototype implementation.

Given the widespread use of password authentication in online correspondence, subscription services, and shopping, there is growing concern about identity theft. When people reuse their passwords across multiple accounts, they increase their vulnerability; compromising one password can help an attacker take over several accounts. Our study of 49 undergraduates quantifies how many passwords they had and how often they reused these passwords. The majority of users had three or fewer passwords and passwords were reused twice. Furthermore, over time, password reuse rates increased because people accumulated more accounts but did not create more passwords. Users justified their habits. While they wanted to protect financial data and personal communication, reusing passwords made passwords easier to manage. Users visualized threats from human attackers, particularly viewing those close to them as the most motivated and able attackers; however, participants did not separate the human attackers from their potentially automated tools. They sometimes failed to realize that personalized passwords such as phone numbers can be cracked given a large enough dictionary and enough tries. We discuss how current systems support poor password practices. We also present potential changes in website authentication systems and password managers.

Most of the recent work on Web security focuses on preventing attacks that directly harm the browser’s host machine and user. In this paper we attempt to quantify the threat of browsers being indirectly misused for attacking third parties. Specifically, we look at how the existing Web infrastructure (e.g., the languages, protocols, and security policies) can be exploited by malicious Web sites to remotely instruct browsers to orchestrate actions including denial of service attacks, worm propagation and reconnaissance scans. We show that, depending mostly on the popularity of a malicious Web site and user browsing patterns, attackers are able to create powerful botnet-like infrastructures that can cause significant damage. We explore the effectiveness of countermeasures including anomaly detection and more fine-grained browser security policies.

The web has become an indispensable part of our lives. Unfortunately, as our dependency on the web increases, so does the interest of attackers in exploiting web applications and web-based information systems. Previous work in the field of web application security has mainly focused on the mitigation of Cross Site Scripting (XSS) and SQL injection attacks. In contrast, Cross Site Request Forgery (XSRF) attacks have not received much attention. In an XSRF attack, the trust of a web application in its authenticated users is exploited by letting the attacker make arbitrary HTTP requests on behalf of a victim user. The problem is that web applications typically act upon such requests without verifying that the performed actions are indeed intentional. Because XSRF is a relatively new security problem, it is largely unknown by web application developers. Furthermore, XSRF attacks can be quite subtle and not always easy to understand and avoid. As a result, there exist many web applications that are vulnerable to XSRF. Unfortunately, existing mitigation approaches are time-consuming and errorprone, as they require manual effort to integrate defense techniques into existing systems. In this paper, we present a solution that provides a completely automatic protection from XSRF attacks. More precisely, our approach is based on a server-side proxy that detects and prevents XSRF attacks in a way that is transparent to users as well as to the web application itself. We provide experimental results that demonstrate that we can use our prototype to secure a number of popular open-source web applications, without negatively affecting their behavior. 1

We describe a new attack against web authentication, which we call dynamic pharming. Dynamic pharming works by hijacking DNS and sending the victim’s browser malicious Javascript, which then exploits DNS rebinding vulnerabilities and the name-based sameorigin policy to hijack a legitimate session after authentication has taken place. As a result, the attack works regardless of the authentication scheme used. Dynamic pharming enables the adversary to eavesdrop on sensitive content, forge transactions, sniff secondary passwords, etc. To counter dynamic pharming attacks, we propose two locked same-origin policies for web browsers. In contrast to the legacy same-origin policy, which regulates cross-object access control in browsers using domain names, the locked same-origin policies enforce access using servers ’ X.509 certificates and public keys. We show how our policies help two existing web authentication mechanisms, client-side SSL and SSL-only cookies, resist both pharming and stronger active attacks. Also, we present a deployability analysis of our policies based on a study of 14651 SSL domains. Our results suggest one of our policies can be deployed today and interoperate seamlessly with the vast majority of legacy web servers. For our other policy, we present a simple incrementally deployable opt-in mechanism for legacy servers using policy files, and show how web sites can use policy files to support selfsigned and untrusted certificates, shared subdomain objects, and key updates.