Leviathan’s (Mandatory) Heartbleed Blog Entry
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.
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.
SpiderOak’s Crypton: Design and Implementation Evaluation
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 server can 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.
Use of Windows exception handling metadata
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 V0.1 [email@example.com]
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>.
Who needs cracking? Give me the plaintext!
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).
Understanding the Windows Allocator: a Redux
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.
First, some prerequisites.
PEAP at DEF CON 21
Last year Moxie Marlinspike and David Hulton presented "Defeating PPTP VPNs and WPA2 Enterprise with MS-CHAPv2" at Defcon 20. Moxie's blog post  describes how DES is still relevant in 2013. Their cracker  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 , 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.
The Digital Pickpocket
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.
2013 Verizon DBIR Thoughts
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.
Zero-Permission Android Applications Part 2
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.
Zero-Permission Android Applications
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.
The Double-Edged Sword of HSTS Persistence and Privacy
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.
Analysis of Adler32
Original Research May 9, 2011
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 . 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.
Why Authenticity Is Not Security
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.
An Illustration of the Dichotomies in Security Industry Reportage
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 2010 Security Predictions
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.
Stuxnet Speculation Jumps the Shark
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:
I’ve had a bunch of SCADA security experience back in the day, and specifically with WinCC, so this path looked strangely familiar.
Moving Targets: Location-Based Threats and Mitigations
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.
More Bugs in More Places: Security Development on Mobile Platforms
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 our Blog
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.