Here’s a story: you have built the ultimate AppSec program for your organization, and you complete the vital step of scanning your code for vulnerabilities along the development process. Your policy was very clear and strict about high priority vulnerabilities while lower vulnerabilities are addressed when time permits. Having achieved a significant coverage, you’re left with only three medium-severity vulnerabilities. You are about to sign off on the release; what could go wrong?
Watch as a downloaded app is attacked through a live demo, and learn the real dangers of three of the most commonly found (and ignored) medium level vulnerabilities.
Join this session to
• Watch how, when leveraged properly, medium level vulnerabilities become serious attacks
• Understand why static source code analysis is vital to locate vulnerabilities that your pen tests are likely to miss
• Learn how to use static application security testing as an attack technique
OWASP iGoat is an open source self-learning tool for iOS developers, mobile app pentesters. The best thing about iGoat is that it follows client-server architecture and supports all iDevices including iPad, iPhone, iPod and Macbook simulator for iOS 8/9/10. It was inspired by the WebGoat project, and has a similar conceptual flow to it.
As such, iGoat is a safe environment where iOS developers can learn about the major security pitfalls they face as well as how to avoid them. It is made up of a series of lessons that each teach a single (but vital) security lesson.
The lessons are laid out in the following steps:
Brief introduction to the problem.
Verify the problem by exploiting it.
Brief description of available remediations to the problem.
Fix the problem by correcting and rebuilding the iGoat program.
This talk is all about how iOS developers, security analysts can dive deep into iOS App Security using iGoat tool. This talk will start from setting up iGoat to exploiting latest exploits in iOS app. I’ll also release a new version of iGoat with tons of new exercises at Appsecusa 2017.
The information security industry has a long history of challenges when it comes to ensuring the safety of user input data. User input must be escaped when using a template to build a string. Whether in HTML, SQL, or shell commands it is best practice to escape data from untrusted sources. Most of the time this is done by having the developer think through all possible code paths the string could have taken. This requires heroic effort and is still error-prone. Far more reliable is using a type or metadata system to tag the data and track it through the system, but this requires the designer of the system to consistently use the tagged string types, or have some additional runtime support to provide a tracking mechanism. Further, such techniques (explored extensively in academic research) have invariably encountered severe performance impacts, making them unpractical for runtime protection.
We propose a black-box taint tracking system in which we observe only the user inputs (http parameters) and system outputs (commands and SQL queries). By parsing the input and the output commands we can determine if an input data partition straddles an output data partition. This would indicate that the input data partition had injected information from the data portion of the input to the command portion of the output. Since we look only at the input and output of the application code, code complexity is arbitrary. Previously, if a system was not designed from the beginning to have taint tracking, introducing taint tracking was cost prohibitive. “Approximate taint tracking” allows after-the-fact introduction of these protections in a way that is cost-effective, and performant.
2017 WASPY Awards
Each year there are many individuals who do amazing work, dedicating countless hours to share, improve, and strengthen the OWASP mission. Some of these individuals are well known to the community while others are not.
The purpose of these awards is to bring recognition to those who "FLY UNDER THE RADAR". These are the individuals who are passionate about OWASP, who contribute hours of their own free time to the organization to help improve the cyber-security world, yet seem to go unrecognized.
HTTP/2 is the second major version of the HTTP protocol. It changes the way HTTP is transferred “on the wire” by introducing a full binary protocol that is made up of TCP connections, streams, and frames, rather than a plain-text protocol. Such a fundamental change from HTTP/1.x to HTTP/2, means that client-side and server-side implementations have to incorporate completely new code in order to support new HTTP/2 features. This introduces nuances in protocol implementations, which, in return, might be used to passively fingerprint web clients.
Our research is based on more than 10 million HTTP/2 connections from which we extracted fingerprints for over 40,000 unique user agents across hundreds of implementations.
In the presentation, I intend provide the following:
• HTTP/2 Overview
- Introduction into the basic elements of the protocol
- a review the different components chosen for the fingerprint format (alongside a discussion on those left out)
- Potential use cases of the proposed fingerprint
- Usage Statistics - prevalence of HTTP/2 usage on Akamai’s platform
• Examples of common HTTP/2 Implementations & Client fingerprints collected during the research
• HTTP/2 support (or the lack of) among common web security tools (Burp suite, sqlmap, etc.)
• Review of attacks over HTTP/2 observed on Akamai’s platform
References:
http://akamai.me/2qWIqON - whitepaper published by Akamai’s Threat-Research Team.
What if you could turbocharge your web hacking without having to sacrifice efficiency? Since pure automation misses so much important information, why not use powerful alerts created from real threat intelligence? What if you had these powerful alerts in as a plugin in a tool that that is so ubiquitous in web hacking that it’s synonymous to its very definition? What if this plugin not only told wyou where to look for vulnerabilities, but also gave you curated resources for additional exploitation and methodology? What if you could organize your web hacking methodology inside of your tool? Well, dream no more! HUNT is a new Burp Suite extension that aims to arm web hackers with parameter level suggestions on where to look for certain classes of vulnerabilities such as SQL Injection, Command Injection, Local/Remote File Inclusion, and more! The data that drives this plugin are parsed from hundreds of real-world assessments which provide the user with the means to effectively root out critical issues. Not only will HUNT help you assess large, hard targets more thoroughly, but it also aims to organize common web hacking methodologies right inside of Burp Suite. As an open source project, we will go over the data driven design of HUNT and its core functionality.
Detailed Outline
HUNT's core idea is to parse large data sets of web application flaws and transforming the results into a meaningful testing tool. We've taken one of the largest known vulnerability data sets, the bounty data at Bugcrowd, and scrubbed it all down to vulnerability class and parameter name. With this data, we can infer patterns in web application vulnerability locations.
Today, one of the things we struggle with as an industry is manual testing for large, complex applications. With the amount of surface area to cover on assessments, we are forced to rely on automation. And while automation is great, it fails to apply the years of experience we have as pentesters in identifying edge-cases in web vulnerabilities that cannot be easily found by anything other than a human.
HUNT will log and alert commonly vulnerable areas for manual testers to look at based on the collective knowledge of hackers all over the world. This will help break down complex applications into meaningful and testable areas. We are not aiming to replace scanners in this fashion, but instead, we are making sure web hacking gets the manual tester love that it truly deserves.
The tool covers critical vulnerability classes that can be meaningfully parsed at the moment:
SQL Injection
Local/Remote File Includes
Directory Traversal
OS Command Injection
Server Side Request Forgery
File Upload Vulnerabilities
Insecure Direct Object References
Server Side Template Injection
Sections of the Talk
The Problem
Web hacking training lacks detailed tribal knowledge of vulnerability location
Sites are larger and more complex than ever and even harder to test thoroughly with current manual testing techniques and methodologies
No in-tool workflow for web hacking methodologies
The Data
Understanding the data set
Learning about data and patterns discerned
Give examples of the data of vulnerable parameters
Examples: file, document, folder, style, pdf
The Tool
Explore HUNT's install and GUI
Explore some sample alerts live
Explore HUNT's methodology and tester references
Explore HUNT's methodology organization tab
Talk about the future and contribution
2016 was the year of Java deserialization apocalypse. Although Java Deserialization attacks were known for years, the publication of the Apache Commons Collection Remote Code Execution (RCE from now on) gadget finally brought this forgotten vulnerability to the spotlight and motivated the community to start finding and fixing these issues.
One of the most suggested solutions for avoiding Java deserialization issues was to move away from Java Deserialization altogether and use safer formats such as JSON. In this talk, we will analyze the most popular JSON parsers in both .NET and Java for potential RCE vectors.
We will demonstrate that RCE is also possible in these libraries and present details about the ones that are vulnerable to RCE by default. We will also discuss common configurations that make other libraries vulnerable.
In addition to focusing on JSON format, we will generalize the attack techniques to other serialization formats. In particular, we will pay close attention to several serialization formats in .NET. These formats have also been known to be vulnerable since 2012 but the lack of known RCE gadgets led some software vendors to not take this issue seriously. We hope this talk will change this. With the intention of bringing the due attention to this vulnerability class in .NET, we will review the known vulnerable formats, present other formats which we found to be vulnerable as well and conclude presenting several gadgets from system libraries that may be used to achieve RCE in a stable way: no memory corruption -- just simple process invocation.
Finally, we will provide recommendations on how to determine if your code is vulnerable, provide remediation advice, and discuss alternative approaches.
Crowdsourcing security aka Bug Bounty Programs are adapted by almost all companies today: big, small, mid size. While companies reap a lot of benefits, the challenge is to have a security engineer/engineers reproduce each of the bug, understand the replication method and spend time recreating the security bug that the researcher reported. And sometimes (read all the time) it may also require a lot of going back and forth with the researcher to reproduce the vulnerability. As security engineers we felt the pain as well and we created a tool that solves this challenge and helps organization focus their resources on resolving these vulnerabilities and strengthening their security posture.
Our tool is an open source software and an easy to install chrome/firefox extension. A researcher can install this extension on their browser and record the entire walkthrough of the vulnerability. Our tool captures not only the screen but even Network requests. So, a researcher can capture the entire session and submit this video to the organization. Then the security engineers who validate this can play the video on the tool and see the exploit in action. This makes triaging much easier, saving engineers valuable time. We will be releasing this tool to the community.
SQL Injection has long been a common dangerous vulnerability found in many web applications. But many modern web applications forgo the use of SQL in favor of more modern databases commonly referred to as “NoSQL” databases. These databases don’t just use different storage engines, but also provide different query language. Some of the limitations imposed by the query language make traditional injection attacks less likely. But with different query languages and probably even more importantly different more complex datatypes come new classes of vulnerabilities which in the end can be as dangerous and exploitable as SQL injection. In addition, many of these new databases lack some of the more granular security and access controls developers are accustomed to from traditional SQL databases. In this talk, we will survey popular NoSQL databases to compare different threats an application may be exposed to by using these databases. We will also demonstrate some new attacks that instead of focusing on injection of query language commands take advantage of new complex data types like JSON and how they can be manipulated to bypass application level access controls to access or manipulate data.
Current Man-in-the-Browser (MITB) trojans like Trickbot or Dridex are pretty much similar to first generation bots like Zeus or Zbot. They all include a list of targets and corresponding webinjects and still offer essentially the same features such as keylogging, form-data harvesting, and remote control (RAT) capabilities.
Today, we are seeing a number of client-side defense proposals being rushed through the standardization process, such as CSP, Subresource Integrity and HPKP. In part, these standards are a response to the permissiveness of the browser against injection attacks.
We argue that it is important to understand how effective these standards can be against MITB attacks specifically and anticipate how attackers will evolve the MITB trojans in an attempt to defeat those defenses.
In this talk, based on our work, we fast-forward to a not so distant future of MITB attacks by demoing a home grown MITB trojan that: 1) is resistant to a number of current defenses by tampering with headers and by exploiting JavaScript code polymorphism; 2) holds capabilities that range from credential and data leakage to website hijacking. We'll also cover approaches to defeat these next-gen trojans by employing similar code attacking techniques and demoing how to detect and react to these trojans.
This talk is organized in four sections: 1) Man-in-the-Browser (MITB) evolution, 2) Client-side defenses, 3) Crafting the next-gen MITB trojan, and 4) Conclusions and future work.
In the first section, we will present a quick chronological evolution of MITB trojans. We will review important concepts like Browser Helper Objects (BHO), Web Injects, Form Grabbing, Stored data exfiltration, keylogging, etc. Most of these concepts are still relevant as current generation MITB trojans are still very similar to first generation bots like Zeus.
We will focus on some capabilities that were added to trojans to bypass defenses. Even though through the years, they evolved very little, we have seen some trojans moving from static to dynamic webinjects, allowing the attack to adjust to the rollout of new defenses; we have seen them become more resilient to AVs and to static and dynamic analysis; employing Domain Generation Algorithms (DGA) to remain connected with their C&Cs; and even trojans that are able to tamper with HTTP headers (e.g. Tinba). Other traits such as the use of reverse connections via proxy and Remote Access (RAT) capabilities will be covered too.
In section 2, we will cover a number of different defense mechanisms/techniques - some of which are still being standardized - such as Content Security Policy (CSP), Subresource Integrity, JavaScript Sandboxing, WAFs, User behavior analytics and Device Fingerprinting. We will discuss how effective they can be against current MITB attacks and where they fall short. We will draw strategies that can be followed by MITB trojans to defeat or bypass these defenses/techniques.
In section 3, we will dive into the goodies. We will present the capabilities we have designed using a modified implementation of Zeus. These capabilities include HTTP header manipulation, to for instance defeat CSP and other types of defenses based on HTTP headers; the use of metamorphic and polymorphic JavaScript, to avoid detection; etc. We will also explore advanced scenarios like the use of HPKP suicide attacks conveyed by MITB trojans. A demo of our Trojan will be shown at this point.
In section 4, the discussion will move on to identify the strategies that can be followed to fight our bot. We will give our opinion on where the appsec community needs to focus next, in order to be prepared for more sophisticated MITB attacks. We’ll draw our conclusion and present our ideas for future work.
Global organizations have been working off of a broken or non-existent threat model. Distracted with compliance, plagued with undefined attack surfaces, a deluge of inoperable threat intel, risk distortions, and made complacent by a sea of controls, *Sec practitioners should feel compelled to reboot their approach. This talk will exemplify how key OWASP projects can truly bootstrap the smallest of *Sec groups to make a measurable impact to applying security through measurable technology in lieu of security smokescreens that plague our industry. Come hear an OWASP commission for change and hear how an OWASP security mesh can exemplify a model that can be imitated by audience members to apply to their own respective security programs and overall companies.
