Fastly offers a content delivery network (CDN) that ubiquitous and high-profile web properties like GitHub, Pinterest, and The New York Times rely on for performance, reliability, and security of their web applications. Fastly edge nodes seamlessly execute customer app security controls, handle sensitive user session data, and act as a trusted man-in-the-middle for TLS traffic. Edge daemons in the Fastly CDN are largely implemented in C. C has many strengths — including flexibility and performance — but C programs are also susceptible to memory corruption bugs that can lead to catastrophic security issues.
Like any successful startup, Fastly has taken many informed risks without things going terribly wrong, building an implicit optimism around legacy codebases and the organization's ability to continually innovate safely on them. Jonathan Foote, senior security architect at Fastly, will discuss the real-world successes and failures that led to an effective strategy for designing and deploying application security hardening measures that balances industry best practices, limited AppSec resources, and startup culture that is conditioned to think about what is going right versus what could go wrong. This talk will describe a minimum-viable approach for implementing application security controls, using deployment of self-service continuous fuzzing of critical internal C codebases including edge HTTP/2 services and Fastly’s varnish-cache fork as a running example.
According to the 2016 Verizon Data Breach Investigation Report, web application attacks are the top source of data breaches today. During the past decade, address space layout randomization (ASLR) has become a feature present in all major OS and a significant guard against buffer overflows and similar attacks by randomizing the location where system executables are loaded into memory.
While ASLR has been effective at the OS level, the principles have not been applied as a means of securing managed virtual machines and runtime environments. Traditional heuristic methods of protection are increasingly ineffective, requiring new approaches to application security. This talk will explore the past, present and future of Java-based application vulnerabilities before sharing a newly developed technology created as a runtime solution to specifically address code injection attacks as a class.
Name Space Layout Randomization (NSLR) is based on the same principle as ASLR, but applied for the first time as an application security feature for the Java runtime. NSLR hardens the Java virtual machine (JVM) by randomizing the JRE namespace (Java packages). Using NSLR inside the JVM, the ownership of bytecode loading is standardized and unvalidated bytecode fails to be executed. In effect, this makes bytecode tampering and a range of code injection exploits so difficult to execute that they become unfeasible, protecting against known and unknown vulnerabilities, including zero-day exploits.
The Problem
Current approaches for protecting against known code injection attacks in applications that run on managed runtime environments involve applying a patch, fixing the vulnerability or disabling the flawed functionality, if possible.
Alternatively, web application firewalls can mitigate some threats, but are often plagued by false positives.
Zero-day attacks are notoriously difficult to protect against since they are, by definition, unknown exploits.
The Solution
We will present a novel approach to dealing with unvalidated bytecode tampering and a range of code injection attacks. With NSLR enabled, JRE packages and classes such as the java.lang.System class are randomized and renamed. Therefore, any exploit that attempts to invoke java.lang.System will fail, because it will not know the new randomized package name. Since NSLR generates a unique package name every time the JVM boots, it is impossible for attackers to guess the new randomized names. Also, it is impossible to access the randomized host package name from the application, since this randomization is not visible to it.
The randomized host package names are transparent to the guest applications and cannot be viewed or accessed from the JRE. In addition, NSLR prevents brute force attacks by using customizable high entropy (96 to 1,024 bits), which would likely require several thousands of years to crack. Finally, NSLR identifies when a code injection attack is attempted, logs the event and throws a ClassNotFoundException that gracefully terminates the attack.
To summarize, NSLR hardens the JVM by randomizing the JRE namespace, which prevents unvalidated bytecode tampering and a range of code injections from executing regardless of the attack vector and the vulnerability (known or zero-day) that is being exploited.
This approach provides absolute protection against both known and unknown code injection vulnerabilities with zero false positives, and does not require any changes to the application code.
Attendee Takeaways
Unvalidated bytecode tampering and injection in the JVM is a type of code injection attack that was never addressed properly. Code injection attacks rank 6th among 2055 known vulnerabilities according to MITRE.
Currently, the most common approach to protecting against them is to identify and fix/patch those vulnerabilities. This is not ideal, and may or may not be feasible. A firewall, IPS or WAF can be used to try to mitigate code injection attacks, but they are often plagued by false positives. More importantly, all the mainstream JVMs lack the appropriate mechanisms to identify and protect against these types of code injection attacks.
Attendees will leave this presentation with a working knowledge of how the next generation of application security solutions will be used against code injections. In the future, web-based applications will be protected by highly accurate, easy to operate virtualized technology in the runtime.
Attendees will gain:
1. Exposure to recent advances in runtime protection in the application security space
2. Understanding of the most frequently employed unvalidated bytecode attacks in the JVM, where they occur and forms of mitigation
3. Working knowledge of the new, state-of-the-art application security technique neutralizing code injection attacks
4. Unique insight into how these types of solutions are designed and developed from the software architect himself
This talk will introduce a new approach to SDL. At Twilio we call it End to End Security Engineering. It’s End-to-End because it covers the full product lifecycle, from Security Design to Monitoring and gives the ability to measure the state of security at each point.
The approach defines a ‘perfect secure system’ and produces metrics which tell us where we are relative to that perfect system.
The final state of the product’s security and risk depends on ‘collective understanding’ of threats and attacks as well as investments in building controls, tests and detections. Then we measure and adjust them to improve their effectiveness.
A perfect secure system is one for which:
- All products and features are threat modeled
- All possible attacks are identified
- All attacks are being monitored for
- All attacks are protected with controls
- All controls are covered with tests which check validity of implementation
- All controls are shown to be effective
To measure this we keep track of the following metrics:
- % of threat modeled products/features
- experience of threat modelers
- % of attacks being monitored
- % of attacks with implemented controls
- % of controls covered by full tests
- # of successful attacks
- # of prevented attacks after control has been put in place
We will map the GDPR requirements to the typical software security activities as part of a Secure Development Lifecycle. This will cover:
• How to include the DPO as part of the software security governance?
• Providing privacy awareness training to developers
• Including privacy in secure coding guidelines
• Including a Privacy Impact Analysis as part of software risk analysis.
• Mapping the GDPR to software security requirements
• Applying privacy by design on software architecture
• Including privacy threats in software threat modeling
• Including a privacy security checklist as part of software security testing
• Applying GDPR specific breach notification requirements on the vulnerability and incident management processes
The talk will focus on practical implementation aspects and demonstrations of real life use cases encountered in our software security and privacy projects.
More details can be provided in a detailed submission.
Our goal was to fix as many high-risk vulnerabilities throughout the GitHub Open Source project portfolio as we could with a minimum of effort. The intent was to simulate portfolio wide remediation in a large and diverse organization within a context that allows sharing concrete statistics and experiences.
Fixing XSS throughout a portfolio of applications is more challenging than fixing a single application. In addition to the remediation work required for a single application, fixing a portfolio requires getting developer buy in, complying with various coding style guides, integration with each project’s existing processes, testing, metrics, and more.
This presentation will discuss how we did it, lessons learned, as well as some alternatives. Three things that made our scaling approach unusual was:
1) Focusing on risk broadly across application portfolios instead of a single application.
2) Focusing on adding missing security controls instead of the exploitability of vulnerabilities.
3) Automating JSP source code modification
We will compare the approach that we used on this project to more traditional manual and automated techniques that focus on vulnerability detection, as well as scaling through training, and scaling through building offshore capabilities.
This session will cover a real-word approach to an enterprise wide, multi-factor authentication deployment at a fortune 500 financial services company with 30,000+ workforce. We’ll discuss the technical challenges we faced in adapting modern passwordless authentication protocols such as SAML and Kerberos to a wide range of client computing devices and legacy technologies. We’ll also discuss the critical user experience decisions and lessons learned during the implementation to enable workforce authentication any time, any place, and any device.
Part One: The Problem
The current solutions of sensor based perimeter defense have their limitations. Taking home defense as an example, sensors are located at all possible breach points of the perimeter (windows, doors, etc). The alarm is triggered only when there is an actual perimeter breach. It takes time for the alarm company to report to local police and more time for police to send patrol cars. If the attackers are determined to finish the task quickly and take off before police can arrive, the chance of getting away is very high.
There is one important additional weakness: this traditional method is limited to what information the sensors pick up. The old methods have no capability of identifying the reconnaissance, which happens very often before potential breaches.
Part Two: The Solution
Most attackers carry cell phones during reconnaissance and the actual breach. This means the chances that a new cellular device will show up near the (potential) breach site is very likely.
I propose a solution of using software-defined radio to simulate cell tower signals within a short range, near the protected perimeters of a site. Through the analysis of abnormal devices within a certain range of the perimeter, we can:
* Identify potential threats (reconnaissance, following, etc).
* Post-breach investigation (by providing cellular device info).
* Conviction (crime scene presence through the location of the device).
Part Three: Technical Implementation Details
SDR Configuration
* (The following SDR config is done only to a short range around the protected perimeter.)
* Use SDR to simulate the cell tower within a short range.
* SDR will force cell phones to downgrade to 2G for information gathering.
* Frequency to power on the SDR. The SDR will NOT always be powered on. It only powers on every 30 minutes, for 1 minute.
* SDR will capture the phone number, active time, and location (directions related to the SDR).
Data Storage
The following data will be stored and encrypted:
* Phone number
* Active time
* Location (relative to the SDR)
Data Analysis
* Normal pattern (learning process): 1) Devices frequently showing up near perimeter (neighbours). 2) Devices only showing up at certain times of the day (mail delivery, garbage pickup, etc).
* Exception pattern: Devices near perimeter that have never show up before (potential reconnaissance).
Identify intrusion: Devices inside the perimeter that have never show up before.
* Correlating the exception pattern with intrusion: identify and note the reconnaissance activity.
Part Four: Limitations and Thoughts
Limitations
* The solution assumes attackers carry cellular device during the recon or breach.
* The location and direction of the device is based on signal strength and is therefore not guaranteed to be accurate.
Integrate with Other Solutions
* Integration with existing perimeter defense solutions
* Trigger the action of drones for 1) vehicle identification 2) real time images
Part Five: Video Demo
Disclaimer:
This article and any related technical detail was prepared or accomplished by the author in his personal capacity. The opinions expressed in this article are the author's own and do not reflect the view of author’s employer
CSRF vulnerability is one among the OWASP top 10 and detection of this vulnerability in web applications has proved to be a difficult problem. Most dynamic application security testing tools provide the option of scanning for CSRF vulnerability, however their reports are often plagued with either false positives or false negatives making them quite unreliable. In this presentation we will analyze the general approach taken by the tools for CSRF vulnerability detection and identify the reasons behind their failures. Then we propose a new programmatic approach to scan for CSRF vulnerability that overcomes these shortcomings. We will demonstrate that this approach is not only simple and reliable but also can easily be integrated with automated testing for application security.
Many web applications contain security vulnerabilities that enable attackers to access sensitive data or gain control of client computers or the servers on which those applications are running. These vulnerabilities are caused by web applications failing to correctly sanitize input data and to safely format output data. Many tools and techniques have been created to detect and correct these problems in web applications written using widely-used programming languages such as PHP and Java but little has been done to address vulnerabilities in web applications written using aspect-oriented languages such as AspectJ. This presentation will introduce a new method of detecting potential vulnerabilities in aspect-oriented web applications.
We have been conducting ongoing research on the dynamics of credential theft. Our intent was to learn about how accounts are being taken over once credentials are compromised through a Phishing campaign. It is a "victim's POV" approach to Phishing research that has not been taken to date.
In our "beyond takeover" research, we maintained 57 fake identities through a period of 6 months in platforms well-known as phishing targets like Google and Facebook. We invited attackers in by admitting the credentials of these accounts to selected phishing campaigns and traced the activity of the attackers in the accounts.
In this session, we will share our findings from this research. We will present takeover stories and some statistics for interesting questions. After falling into a phishing trap and giving one's password to a fake site, how long does is take until someone will actually get into his or her account for the first time? What does the attacker look for in the hacked account? Where do they look first and which decoys attract their attention? Which security practices do attackers use when sniffing out a hacked account (hiding their geo-location or covering their tr