Like many others in the security industry I sat down last night to watch the first episode of CSI: Cyber, the latest of the CSI franchises, following the work of special agent Avery Ryan and her team. Special agent Ryan is a CyberPsychologist who heads up the Cyber Crime Division of the FBI.

As expected the episode caused a good number of laughs and facepalms to those of us who work in all areas of the security industry, not just forensics. As an industry we took to twitter to poke fun at the misuse of terminology, made up jargon and unrealistic processes and procedures that were used by the investigators. Others in the industry have pointed out that it is just entertainment and that some elements are in fact correct.

How we store data---and how we think about keeping our memories available over the long term---has changed in the last few years. The world has become better at keeping data secure and safe by distributing it to multiple continents. However, some leaders are calling for "national Internets"---censored, walled gardens set up to appease special interest groups that range from political factions, to property cartels, to religious police. Other leaders have taken a different tack, called forced localization; rather than blocking your communications, they want to require that all your data (and all the computers that handle it) be inside a single country: theirs, for whichever country they represent. These would be major changes to the structure of the Internet---changes that would harm both businesses and the general public.

Currently, services on the modern Internet are built with "cloud computing"---the idea that services that you use, from Facebook, to Google, to Netflix, should store your data in many different, geographically diverse places, as well as close to where you are.

Scarcity of cybersecurity experts is a real problem that can be quantified and described---but not one that can easily be solved. Limited resource availability, the basis for our entire economic system, is ordinarily a problem of finding raw materials or advanced machinery, not one of hiring the workers we need to defend our assets---but with more than one million cybersecurity positions unfilled worldwide, currently-identified cybersecurity needs could not be met if every employee at GM, Costco, Home Depot, Delta, and Procter \& Gamble became security experts tomorrow. Those one million positions span all industries, specializations, and requirements, and include approximately 25,000 non-military positions in the United States' federal civil service.

This resource problem is too large and cannot be solved by individual corporations, leaving countries to confront this issue with essentially two options: import existing talent from other countries, or educate new cybersecurity talent.

Importing talent seems like a simple solution: find the experts and entice them to immigrate temporarily or permanently.

We are pleased to announce the release of our three whitepapers on the value of cloud computing as it relates to security issues around data storage, in the areas of data availability, scarcity of expert security talent, and the infrastructure and hardware investment to set up new data storage solutions.

We spent several months exploring the value proposition of storing data in the cloud from a security perspective. We wanted to know whether cloud storage is more or less secure than storing data in a local datacenter, for all the different definitions of secure. We wanted to know whether data can be kept confidential, whether data remains available despite localized outages, whether the supply chains that make maintenance of local data centers can be preserved (and at what cost), and whether companies are able to hire sufficient security expertise to defend their investments in storage.

On Robbing Banks

Willie Sutton was quoted as having said the above (he denied coining the phrase) in response to the question, “Why do you rob banks?” At the time, it was an obvious choice; in a pre-networked world, value was primarily transmitted by moving physical objects around the world, whether they were bars of precious metals, mineral crystals, or slips of paper.

Summary

After creating and using a new exitmap module, I found downloaded binaries being patched through a Tor exit node in Russia. Tor is a wonderful tool for protecting the identity of journalists, their sources, and even regular users around the world; however, anonymity does not guarantee security.

Background

At DerbyCon this year I gave a presentation of my binary patching framework, BDF. Many binaries are hosted without any transport layer security encryption.

Intro

It's been 5 days since the release of CVE-2014-0160, better known as Heartbleed. This vulnerability in the OpenSSL security suite utilized by a significant portion of the webservers on the Internet - perhaps half a million as well as many other security and encryption products. In this posting, we'll provide some insight and detail for the two main viewpoints, Business Risk and Technology, before walking through some Considerations which we feel are crucial to conclude an organization's response to the vulnerability.

Business Risk

So much of the effort put forward this week has been about the technology and many organizations are lagging in the business understanding necessary to deal with vulnerabilities of this size and nature.

Leviathan recently took a critical look at a technology currently in development by SpiderOak called Crypton. Crypton, an open-source project hosted on github, aims to be a zero-knowledge, cryptographically-secure storage framework upon which zero-knowledge cloud applications can be written. Its primary functional goal is to provide assurance that data stored on the servercan only be read by the client who possesses the key and cannot be read by the server or anyone else.

For the version Leviathan reviewed, Crypton was still in development, and we would characterize its readiness as “pre-alpha.” As we write this, major components are still being written while others are being rewritten.

64-bit Windows and the Intel 64 environment have brought a number of changes to the way processes interact with their environment. Among these is the elimination of the base pointer by default, and with it, the ability to unwind the stack based only on the values of the stack and base pointer and the values at these locations on the stack. This frees RBP up for use as a general purpose register in addition to the 8 new ones introduced in the new architecture.

When an exception occurs, one of the first things to do is to unwind the stack looking for a handler; this involves looking through each stack frame starting with the current one, looking for a frame corresponding with a function we know how to handle exceptions in. In order to do this, we need some mechanism of determining the length of stack frames, which is variable; otherwise, we have no way of knowing which address will be returned to and can't determine the identity of the calling function.

ftrace is a reverse engineering tool designed to help map out the execution flow of ELF executables (32bit and 64bit). Instead of printing system calls or library function calls, it prints out the local function calls as they are happening, and attempts to retrieve the function arguments and determine whether they are immediate or pointer type. As of version 0.1, function arguments are only shown for 64bit executables. This program is useful when wanting to see the function flow of a given executable during runtime without having to set incremental breakpoints and backtraces in a debugger like gdb. Ftrace relies on symbols for seeing a functions actual name, but the -S option will show function calls for functions without symbols as well, displaying them as sub_<addr>.

Another Defcon has come and gone. As far as I know, everybody I went with made it back safely, so I consider it a great success!

One of the most frightening things I learned this year was the existence of a tool called Windows Credential Editor (or "WCE"). As far as I know, this wasn't covered in any particular talks, but I had several offline conversations with password researchers. They all told me how downright terrifying this tool is.

Now, I used to be fairly deep in the password game. I competed in Korelogic's Crack Me If You Can challenge the first year it was out (my team ranked second place of eligible teams, with about 1/5 the size of larger teams). I've hosted (and still host) countless password lists, and I almost finished a database-driven breach site (I'll finish it one day, I swear).

If you are interested in Windows heap allocator behaviour, and you haven't already read Chris Valasek's papers Understanding the LFH and Windows 8 Heap Internals (credit also due to Tarjei Mandt), I strongly suggest you do so. There are few more detailed and accurate accounts of the modern (post-XP) allocators' behaviour. However, as I was working on our crashdump analytic software (codenamed Major Myer), I found that there is some additional depth of functionality not addressed in these two papers; I present it here.

History

Last year Moxie Marlinspike and David Hulton presented "Defeating PPTP VPNs and WPA2 Enterprise with MS-CHAPv2" at Defcon 20. Moxie's blog post [1] describes how DES is still relevant in 2013. Their cracker [2] turns captured WPA2 handshakes that use MS-CHAPv2 into NT hashes. These hashes can get you onto the network. This wasn't the first attack on MS-CHAPv2. Asleap [3], the MS-CHAPv2 cracker that Joshua Wright wrote in 2003-2008, uses a weakness in MS-CHAPv2 to crack LEAP and PPTP handshakes much faster than brute force.

I am sure that everyone has seen the commercial where users of a specific brand of smartphone are passing a video back and forth by simply touching the devices together. It is a very slick feature that obviously makes moving files between mobile devices an easy task to accomplish.

The technology being used to provide this feature is known as Near Field Communications (NFC). This same technology, which is an extension to older Radio Frequency Identification (RFID) technology, is also being integrated in other facets of our lives under the banner of convenience. Unfortunately, like anything where convenience is the priority, there are some potential security issues that the security community has been pointing out for years. In this case we are talking about “Tap to Pay” credit cards, transit cards, and other cards that use NFC to broadcast payment information to payment terminals.

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.

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.

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.

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.