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.

As previously mentioned, NFC is an extension to RFID technology.  RFID technology, typically used to track inventory, is (I am over simplifying here) essentially a small radio transmitter that requires little to no power.  The main difference, which according to many NFC vendors is a security feature, is that RFID allows for a longer range transmission than NFC.  Essentially NFC will work when the devices are inches apart while RFID can be meters apart.  If you want the real geeky details on exactly how NFC works I suggest that you give the ISO standard (ISO 18092) a read. 

To read a NFC transmission or even an RFID one for that matter one simply needs to have a receiver that is within range of the transmitting device.  I would like to tell you that this transmission is performed over cryptographically secured channels or that only an authorized receiver may pick up the transmission but unfortunately, this is not always the case.

This week we had an opportunity to talk with KOMO TV News Reporter Matt Markovich about NFC technology and some of the risks it presents when used as a payment mechanism.  I would say that my impression of Matt was that he is more technical that most reporters I have worked with in the past as when he approached Leviathan for assistance on his story, he already had a working test case that helps prove the threat.

What Matt was proving (video below) was that this technology of convenience is not secure from an eavesdropper or interception.  Essentially, a “bad guy” can build his own receiver and as long as he is within the necessary range read the transmission coming from the NFC enabled card.  In Matt’s test case, he uses Visa credit cards however, with a bit of customization work this can be extended to read other types of NFC enabled cards such as transit passes, and door locks.

When watching the video remember no vulnerability is being exploited this is simply leveraging a feature of the technology, not a bug.  NFC is after all simply a radio transmitter, there is no access control or authorization required to accept that radio transmission. 

It is also important to understand that this is different than some of the ways we have seen RFID technology leveraged by attackers.  In the past attackers have built low cost devices like this Proxmark one pictured below to read RFID enabled devices;

While a setup like this could easily and just as cheaply be built (less than 100$) to read NFC this is not exactly portable or discrete which are two things that an attacker will require due to the fact that in order to read the NFC chip the attacker must be within range which for NFC is no more than 4 inches.

In addition, the above setup assumes that, even if you follow one of the many online tutorials, you must have a level of competence when it comes to building your own electronics.  So, instead of going to all of this trouble and to insure a more stealthy mechanism for attack we go back to the beginning of this post and the wiz bang smartphone feature found on most Android smartphones that allows you to transfer data simply by touching the devices together.

Security researchers were quick to leverage   the native NFC support found in most Android phones plus the powerful features of the smartphone itself to make this attack stealthy and practical.  By simply running a custom, community supported version of the Android Operating system as well as publically available apps one can turn their smartphone in to a NFC receiver and accept a transmission.  Not only can one receive the transmission, which by the way contains all the data needed to “borrow” the target’s credit card details, but it can be saved and then replayed at a later date or relayed in real-time from the smartphone to make a purchase at any standard “tap to pay” terminal.

This is exactly what Matt did and demonstrates in the video and explains in this article.

The most common response to this sort of attack is typically something along the lines of; “yes, but you need to be within 4 inches to make this work.”  In fact, this is exactly what MasterCard said in response to the KOMO News inquires; "The circumstances under which it can occur in the real world are extremely rare."

This is absolutely true however thieves already have no problem performing a traditional pick pocket theft, so why not instead of actually taking the wallet simply bump in to your target and scan it. 

In cases like this, it is human nature to want to find someone or something to blame.  Before you assume that it is once again those “evil hackers” or organized criminal rings that are responsible remember – this is a feature not a bug.  The demonstration as done by Matt in the video is simply leveraging an existing feature.  This means that if you absolutely must find someone to blame, then you must pick whomever is responsible for implementing such an insecure way to transmit payment data.  Yes you guessed, the Payment Card Industry (PCI).  Let’s be clear, this “vulnerability” exists due to the fact that convenience has outweighed security.  The PCI wanted a way to insure that consumers can quickly pay for items without spending the extra few seconds fumbling with your wallet and counting that dirty paper cash stuff that no one seems to use anymore.

Could the Payment Industry implement NFC technology in a secure way?  The ISO standard does outline various provisions that may add security to the implementation however, considering the scale of this implementation there may be real world operational and technical hurdles that prevent this from happening.

Unfortunately, we will see more and more of this technology however, one of the best defenses today is to simply call your credit card company and ask them to issue you a card that does not support “tap to pay” or any other NFC technology.  Today, card issuers are honoring this request, of course eventually they may stop however, if enough consumers reject the technology perhaps change can be forced.

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.