It's another year - and time for the 2013 Verizon Data Breach Investigations Report. Despite the name, the report references the previous year - 2012. The most notable part of this year's report is that the list of contributors continues to grow up to a total of 19 for this report. This fact becomes really important as you dig into the report which contains a fairly large number of year-over-year comparisons. When receiving the briefing, it was noted that despite there being 5 years worth of data, it's like comparing apples to not-apples.

Thinking about the reports over the years and the industry response, someone with a more recent memory of STATS 101 can probably use better words to describe the change in how the report is consumed, by which groups within organizations and with what focus.

Since my previous post about zero-permission Android applications, I have continued researching along the same lines. This work is similar to research presented by Lookout at Defcon. As that work is a few years old, I thought this topic should be reviewed with fresh eyes.

At Defcon 18, three researchers from Lookout Mobile Security presented on several permission-related security issues. My observation is that most of the research presented was targeted at Android 2.2 and below.

There's been a lot of research in the Android security space. The most notable examples are Jon Oberheide's fake Twilight app, Georgia Weidman's SMS bot, and the numerous clever root exploits. Recently in the mainstream media, there's been buzz about apps (allegedly) misusing permissions; some of these apps include Facebook, Skype, Path, and just about every advertisement library.

One question that was posed internally was: what data can an app access when it has no permissions? I thought this was an interesting question, so I decided to make a proof-of-concept app to explore this idea.

HTTP Strict Transport Security or more commonly known as HSTS is a draft policy by the IETF WebSec working group currently proposed that would extend the standard list of HTTP response headers to allow domain owners to enroll complying browsers into exclusively secure communications with the web server for an asserted period of time.

This is accomplished by rewriting all HTTP requests to that particular domain regardless of entry (be it via link, image or manually typed in the address bar) over HTTPS and validating the certificate chain.

Original Research May 9, 2011

Introduction

Adler32 is a checksum designed to detect corruption in Zlib's compressed data or corruption in the algorithms. Since it was much faster than its more reliable competitor, CRC32 it was chosen for this task [1]. If the uncompressed data does not match the Adler32 checksum, the application can inform its protocol or the user to retransmit the data. However, the main use of Adler32 was to debug implementations of Zlib. Adler32 as well as CRC32 are insufficient for any purpose that requires a high degree of certainty. The chance of a collision for an ideal 32-bit checksum is 1 in 4 billion, which can be easily computed in a few hours by anyone with a reasonable computer.

Code signing aims to solve two specific problems. The first problem is how to identify the author of code. The second problem is how to verify that code has not been modified after release. Truly solving one or the other would be a good step forward. That both may be solved simultaneously is a great step forward. There is a common misconception, however, that code signing represents a giant leap forward by making the signed code itself "secure". There is not a little danger in trusting code simply because it is signed, without regard to the security of its development before release.

First, a primer on how code signing works. Code signing calculates a cryptographic hash of the code, which is then digitally signed by the author and appended to the code itself.

On the front page of Google news just now. The difference in the reporting style between the business and technology press has rarely been more stark.

Failed Security Predictions from 2010

As most of us return from attempts to relax over the holiday season various self-proclaimed information security experts quickly scramble to do press interviews and write blog posts about their predictions on what to expect over the next twelve months when it comes to security. In a tongue in cheek Twitter post, security luminary and privacy expert Adam Shostack mused “My 2011 security prediction: 75% of predictions from people who offered predictions last year won't start with a review of how they did.”

So, before we make some predictions of our own (hey everyone is doing it) let’s review some of the more misguided and wrong predictions made by others this time last year. As I used Bing.com to search for last year’s predictions I quickly realized that not many “visionaries” were really willing to go out on a limb and predict anything that wasn’t already very obvious.

One of the lessons I remember best from my early security career with Uncle Sam was the maxim: “crawl, don’t jump to conclusions.” Having heard of various botanic, historic and religious analysis on how the word “myrtus” - in a build path to a PDB file - clearly indicates that the Israelis are responsible for the Stuxnet worm, I have to conclude that this story has officially jumped the shark.

Here’s what the string in question looks like in ASCII:

b:\myrtus\src\objfre_w2k_x86\i386\guava.pdb

I’ve had a bunch of SCADA security experience back in the day, and specifically with WinCC, so this path looked strangely familiar.

This year at ToorCon 12 in San Diego, California I will give a presentation entitled "Moving Targets.”

Location-based services are built into every major mobile platform, almost every social networking site, and more and more consumer electronics every day. These services, that record and sometimes share their users’ geographical location in real or near-real time, have been deployed by developers and embraced by users with little consideration of the threat posed by this data. An attacker who possesses the user’s location can abuse it to leverage both technical and social engineering attacks on that user.

At the Blackhat Briefings USA 2010 in Las Vegas I gave a presentation entitled "More Bugs In More Places" which was about secure development on mobile platforms.

Nothing succeeds like success, and with the attention garnered by Apple’s App Store, many companies are either looking to port existing applications to or develop exclusive applications for the top mobile platforms: Blackberry, iPhone, Windows Mobile, and Android. Each of these platforms provides the would-be developer with a SDK to do the heavy-lifting of coding, but can they be trusted to carry that weight? Just as some languages make it easier or harder to develop secure applications, so it is with SDKs. One SDK may provide robust cryptographic functions, another may restrict hardware access, and yet another may enforce strict memory management.

Welcome to Leviathan Security Group’s blog. If you need or want to know more about the minds behind Leviathan Security you can read about us here. Our goal with this Internet space is to share our opinions and ideas on Information Security topics. We will periodically write about high to low level technical topics and everything between and maybe some things outside. Posts, like this first one, will sometimes be limited to as few words as necessary, while you can expect us to go much deeper on other topics.

You can also find Leviathan Security Group on Twitter - http://twitter.com/LeviathanSec.