Published on June 22, 2016 by David Lindner
Apple first released its iPhone in 2007, and over the past 9 years we have seen both the hardware and software evolve into what we now know as the iPhone 6s (e, plus) series of devices. These iPhones tout faster processing speeds, tons of data storage, and the ability to determine your blood alcohol level or your baby’s due date.
In 2013, with the release of the iPhone 5s, Apple introduced the capability to “authenticate” to the device via the “TouchID,” their fancy term for a fingerprint reader. With this major release, Apple decided to withhold access to TouchID functionality from any apps that were not Apple branded. This, however, all changed with the release of iOS 8 and the iPhone 6. Now developers could utilize TouchID to make authenticating to their applications much more convenient.
Published on March 31, 2016 by David Coursey
For the second time in a few months I had a conversation with friends on this Fortify finding - Privacy Violation: Heap Inspection.
The description reads:
"Sensitive data (such as passwords, social security numbers, credit card numbers, etc.) stored in memory can be leaked if it is stored in a managed String object."
The threat here is that the string data will remain in memory long enough to be retrieved by an attacker. This is exactly why Heartbleed (TM) was such a big problem--strings in memory could be accessed long after they were no longer being used. If you ran it a bunch of times and were lucky, the exploit would give you passwords or private keys.
Published on March 11, 2016 by Tim Tomes
I recently wrote this article about exploring the true impact of Server-Side Template Injection (SSTI) in applications leveraging the Flask/Jinja2 development stack. My initial goal was to find a path to file or operating system access. I was previously unable to do so, but thanks to some feedback on the initial article, I have since been able to achieve my goal. This article is the result of the additional research.
Published on March 9, 2016 by Tim Tomes
This is the first of two articles covering research into SSTI in the Flask/Jinja2 development stack. This article only tells half the story, but it's an important half that provides context to the final hack. Please consider reading both parts in their entirety. Part 2 can be found here.
As security professionals, we are in the business of helping organizations make risk-based decisions. Seeing as risk is a product of impact and likelihood, without knowing the true impact of a vulnerability, we are unable to properly calculate the risk. As someone who frequently develops using the Flask framework, James' research prompted me to determine the full impact of SSTI on applications developed using the Flask/Jinja2 development stack. This article is the result of that research. If you want a little more context before diving in, check out this article by Ryan Reid that provides a bit more context to what SSTI looks like in Flask/Jinja2 applications.
Published on March 2, 2016 by Kyle Rippee
Love them, hate them, or otherwise in this day and age, CAPTCHAs are a part of everyday life on the web. In this blog we will dig a little deeper into the technology behind CAPTCHAs to find out what they are, why they are used, and how they are created, implemented, bypassed and broken. What are these things, and why are they everywhere?
Published on January 26, 2016 by John Poulin
Tl;dr: If your application uses dynamic render paths (eg: render params[:id]) then you are vulnerable to remote-code execution via local file inclusion. Update to the latest version of Rails, or refactor your controllers.
In this blog post we will be demonstrating the exploitation of a flaw in the Ruby on Rails framework that allows attackers to remotely execute code in certain circumstances.