Not much larger than a quarter, the technology behind it is comprised of a micro controller and other associated electronics (memory, I/O, etc). The result is a very functional, yet flexible, USB thingamabob that can let people program their own logic to run their own routines, commands, and instructions.

Teensy was recently used in a unique demonstration of some interesting security implications that arise from exploiting the USB-to-OS trust relationship. By programming Teensy to identify itself as a keyboard, someone could trigger it to send automated keystrokes at will (or set via timer).

But this has been possible for years. In fact, for this example in-particular, it’s probably desirable for users to not have to do any real configuring to get their keyboard or mouse to work. Perhaps the underlying issue is that many vulnerabilities are introduced when trying to balance convenience with security.

But the flip side might be that real change is coming from the other direction. As technology evolves, it gives attackers more tools with which to express their creativity. A few short years ago, programming logic into a USB device like this might have cost a few hundred dollars of equipment and a good amount of coding, just to do something simple.

Teensy is dirt cheap and there is a software library already written for it. This makes it easy to jump right in and start making stuff because the barrier to entry for this vector has been lowered by better technology. As a tool, a device like Teensy offers potential that is only limited to what the creative individual can fit into the on-board flash memory module. In a way, the bad guys get new toys, while the good guys just get more stuff to patch, secure, and protect against.

And that’s not… a teensy problem.

Before we get into risk measurement, let’s first make one thing clear: risk analysis is nothing more than a decision-analysis (or decision-support) tool. It helps provide reasonably accurate data points that decision-makers can use when make decisions. It is not a panacea for all things risk or infosec, nor is it some sort of special magic-sauce voodoo with no grounding in reality (at least not in terms of well-considered quant methods). Clear? Crystal, I’m sure.

When performing a risk analysis, we need to start with the basics. Here at Gemini we subscribe to the Factor Analysis of Information Risk (FAIR) methodology for performing quantified risk analysis. FAIR defines risk as “the probable frequency and probable magnitude of future loss.” What this means in real terms is that FAIR reduces “risk” into two main components: Loss Event Frequency and Loss Magnitude. Both are estimates that are created using Douglas Hubbard’s calibration technique, as advocated in his book How to Measure Anything.

Hubbard’s approach to measurement is quite simple: start with a range of values and then ask “If I had to choose a winner between my range and spinning a wheel with a winner space covering 95% of the wheel, which would I pick?” (see an example of said wheel at right). Your initial ranges should select absurd endpoints such that you’ll definitely choose the range. However, as you begin to narrow the range, you should then get to a point where you are indifferent between the range and the wheel. If at some point you’d pick the wheel over your range, then you need to adjust an endpoint accordingly. In the end, our range can be said to be “accurate” because the most likely value falls within our estimate. The narrower our range is, the more precise our estimate is.

In this manner, we can then go about producing estimates under Loss Event Frequency and Loss Magnitude. Let’s start with the “easier” concept first: impact. Under the FAIR methodology, we estimate both primary and secondary impact. Primary impact is often straightforward to estimate, and has a higher degree of precision than secondary impact, which by its very definition will have a wider range of potential outcomes. These impacts are further broken down into categories, such as Productivity or Replacement.

On the other side of the tree, we divide Loss Event Frequency into two components: Threat Event Frequency and Vulnerability. In this case, we define vulnerability as “the probability that threat force will exceed resistance strength.” Vulnerability is not, then, used in the traditional infosec lingo use case where it describes a weakness, but instead looks at the capability of a threat agent and the general resistance of an asset to attack.

Finally, Threat Event Frequency is where a lot of the controversy in risk analysis arises. Some argue that there are too many “unknown unknowns” in the world to allow us to make a reasonable estimate around a given threat event. However, this criticism fails to understand how a methodology like FAIR operates. In setting up your risk analysis, you will define a specific asset profile, including whether you’re most concerned with confidentiality, integrity, or availability. You’ll also then define a specific threat agent profile, such as “casual hackers” or “script kiddies” or “professional hackers” etc. However, you’ll go even deeper in defining the threat agent, breaking down this Threat Event Frequency value into an estimate of Contact Frequency (the likelihood that the threat agent will make any sort of contact) and an estimate of the Probability of Action (the likelihood that a threat agent will act against your asset).

There are a few potential weaknesses with these probability estimates. For example, we know that there are likely many cases where professional hackers (organized criminals or nation-state actors) are making contact with an organization and not being detected. Similarly, we may over- or under-estimate the probability that a threat agent will act against us. We can, however, address some of these issues through a couple key approaches. First, if we’re having difficulty defining reasonable ranges, then we need to ensure that our threat agent profile is sufficiently constrained, even if that means starting a second analysis on a separate profile. Second, we need to ensure that our ranges are broad enough to be reasonably accurate before we work to narrow them to an adequate degree of precision.

In the end, having some real-world data, either from aggregate reports or from our own internal infosec programs, will go a long way toward helping refine these estimates. We know that certain events are happening on a regular basis. We know about a wide variety of threat agents who can be reasonably defined and described. And, again, risk analysis tools like FAIR are design to support decision-making, not to replace it altogether. If the results feel wonky, then it’s likely something is off and the numbers need to be re-evaluated. Ultimately, you simply need to ensure that your decisions are well-reasoned, reasonably defensible from a legal perspective, and that they demonstrate a reasonable degree of foreseeability.

Interested in learning more about FAIR? Please let us know!

P is short for Polynomial, and NP is short for Non-deterministic Polynomial. To understand the exact difference requires you to understand Turing machines (usually a senior level CS class). P is the class of problems that can be solved in polynomial time on a deterministic Turing machine in polynomial time, and NP is the class that can be solved on a non-deterministic Turing machine in polynomial time. Here’s the catch: so far, no non-deterministic Turing machines exist. There’s speculation that quantum computers are non-deterministic Turing machines, but not a proof that I know of.

Another way of thinking about P and NP problems is how long it takes for a computer to solve the problems – is it “easy” (P) or “hard” (NP). Most classic computer science problems are NP – the traveling salesman, factoring integers… The computer can verify the answer in P time, so the current approach is to make a best guess, verify it, then make another guess.

What does this mean for most people? Most people have never heard of P or NP – heck, a lot of computer/IT people probably haven’t unless they’ve studied theoretical computer science – and even most of us who’ve heard of it would rather forget it. But it really does matter for security. One of the NP problems is factoring integers – what public key cryptography is based on. There is an assumption – based on years of practice, but no proofs – that NP is not equal to P. If NP were ever shown to be equivalent to P, then our current asymmetric cryptography solutions would be blown out of the water and we’d all have to find new algorithms to use. If NP were proved to be not equal to P, we’ve got some more time

So far, the reviews I’ve heard of Deolalikar’s paper is that it’s a great start, but it has a few flaws, so we still don’t know if P is or is not equal to NP.

Personally, I haven’t seen many big, old-school dot-matrix printers still in operation. But the article suggests that physicians and banks are hoarding them (at least in Germany). This makes them an interesting target for a resourceful attacker.

The researchers were very thorough, trying different microphones and setups to determine the effective range of the attack; the results were impressive. Optimally they can get 72% of printed English text and even better results when they take contextual knowledge into account.

The researchers focused on a real-world scenario of capturing data from a physician’s office. However, I think this research can also be applied to dot-matrix receipt printers that some stores and businesses use. Receipts can contain all kinds of goodies– especially when they include special codes. It’s probably not something to worry about as a real threat to a consumer or business (the process is targeted, awkward, and error prone). Even still, I wouldn’t mind seeing how practical an acoustic attack on those mini dot-matrix printers would be.

Whitepaper here.

With cryptographers constantly working on new algorithms and breaking old algorithms, one may get nervous about whether the foundations of today’s secure transactions are really that secure. But despite the occasional ominous forecast of a cryptographic meltdown, you can remain fairly confident in encryption technology.

Just as we’re constantly finding new weaknesses in various approaches, we’re constantly finding new approaches that overcome various weaknesses. For instance, scientists are working to develop “quantum computers” that perform calculations in a completely different way than today’s electronics. These new machines would be powerful enough to crack several of the strongest algorithms currently in wide use. But just this week, several researchers demonstrated that a 30-year-old algorithm, using a different type of mathematical basis, would foil any known quantum attack. This approach has not been widely used due to large key sizes that would hinder performance, but computers are getting faster every year.

Cryptographers also work to maintain a gap between theoretical attacks and practical compromises. NIST does not wait for programs that can crack any key within seconds before deprecating an algorithm. Researchers are constantly working to build stronger systems, and often start recommending replacements when only the slightest cracks begin to show for a particular approach. Also, one type of weakness does not necessarily ruin every possible use of a given encryption method.

But while the mathematics behind today’s systems may be sound for the near future, strong encryption alone does not guarantee you security. In fact, most security problems come through either insecure implementations of a given approach or bad security practices built on top of strong algorithms. Keeping current with effective cryptography is important, but it’s only one part of an effective security strategy.

1. The signature has to be applied to a carefully crafted PDF file.   A PDF file that you create and sign is unaffected by this attack;  if you examine the data within the file, the presentation data for both the “recommendation” and “order” documents is present in both.  Obviously, you will not be adding rogue data into your own PDFs before signing them.
2. As stated in the article, it’s not really clear that the PDFs used in the proof of concept are syntactically valid PDF files.  However, Acrobat does open and display them as the attack intends, so that may be irrelevant.  Although, an Acrobat security update could fix the issue if this is the case.
3. It appears as though, by looking at the proof of concept documents, that the special construction of the PDF requires precise byte positioning in the file for the various objects used in the attack.  It is not mentioned in the article, but it may not be true that such a document can be constructed with a blank signature field that can be signed in Acrobat and subsequently attacked using this method.

It will be interesting to see what, if any, response Adobe has to this publication.  I know my way around the PDF standard (as it pertains to digital signatures) fairly well, but I’m by no means an expert.  It seems to me, though, that this attack requires several things, including the execution of the initial digital signature, to be performed in a precise way, which may mitigate the risk of the attack working in a real-world scenario.

Well, to help defend Google (which they’ve done a decent job of doing themselves), this one falls back on the users. If you’re an Android user, you’ve most definitely seen a screen similar to this.

This screen tells you exactly (mostly) [kinda] what the application you’re installing has access to, and how far it can reach. It’s your (the user’s) obligation to agree with this and install, or not agree, and cancel out. See those two buttons at the bottom? If you don’t agree and see something that has “Cost Money” in this section and you presumed it was a completely free (as in beer) app, then you’d better click the right (Cancel) button.

Now, the real concern here is what exactly do these actually mean.  If you see a label for “Phone Calls,” should you freak out and immediately think the app is going to start calling your friends, or start making unauthorized long distance phone calls? No (though it might).

This is one area where I think Android needs to step it up. It’s great that they tell you what permission groups are affected by this application. But to be honest, there are quite a few scenarios that could exist in each group. The given example for Phone Calls really only monitors the state of the telephony portion of the OS e.g.: An application could automatically monitor the state of the phone and reject any incoming calls if this happened to be some sort of navigation app, and felt that receiving calls while driving was too much of a distraction. – That’s a fairly obscure example, but it just goes to show what lengths these permission groups can go to. Obviously this same app would most likely pop up the Location group in this section as well as it would be requiring access to the course or fine GPS data.

So what determines which permission groups show up here, and how can you be sure that the developer wasn’t trying to be sly and hide the fact that their application is using the GPS data? Well, the people at Google thought of that. When developing an application, you need to specifically state which permissions groups your application needs in the AndroidManifest.xml file.

<manifest xlmns:android...>
...
<uses-permission android:name="android.permission.LOCATION"></uses-permission>
</manifest>

If this is not included in the manifest, you’re not even allowed to make calls to the classes that implement the functionality located within that permission group. The code simply won’t compile until the manifest file is edited accordingly.

So it seems Google has covered their end fairly well. It’s just up to the users to keep an eye on what they’re installing. Though as stated, I do think they could increase the level of detail that is displayed for each group.

Included below is a table showing all the permission groups. Also if you’d like to have a deeper look at what’s inside each group, have a look at the Android developer site for a full list of all the constants that would indicate what features are being used.

Android Permission Class

Enter Factor Analysis of Information Risk (FAIR), a different sort of beast altogether, created by Jack Jones of Risk Management Insight (RMI). FAIR is a decision support tool that provides a means for performing a quantitative risk analysis around a given scenario. It allows you to conduct deep analysis into given asset+threat scenarios, digging into the business to arrive at accurate estimates (via ranges) for probabilities and expected losses. Loss events are divided between primary and secondary, wherein primary losses are often fairly well known (e.g. how much it costs to replace a server), whereas secondary losses can vary widely.

For an excellent introduction to FAIR, the RMI white paper “An Introduction to Factor Analysis of Information Risk (FAIR)” is highly recommended. In it, you’ll start to see the breakdown of FAIR into its component pieces. Overall, within the context of FAIR we define risk as a derived value measuring “the probable frequency and probable magnitude of future loss.” There is much that can be said about this definition and overall approach, but I’ll leave that for another day. In the meantime, I encourage anybody with an interest in risk analysis to take a deeper look at FAIR.

Apt is the debian packaging system. It’s found in all debian based Linux distros – like K/Ubuntu and Backtrack. If you’re going to be at a hacker conference, the least you can do is update your system before you go! Packages are generally GPG signed by the maintainer, and debian keeps a list of trusted GPG keys updated on your system (debian-keyring debian-archive-keyring are the debian specific packages). Apt checks these signatures to help ensure that you’re not downloading rogue signatures.

Apt has two configuration files. For the most part, you’ll only use one: /etc/apt/sources.list The other (/etc/apt/apt.conf) is used in specific instances – such as with a proxy server.

sources.list has a list of all of the sources (repositories) you’d like to look through for packages. The default list is generally OK for non-desktop (i.e. server) users. If you’d like to install various media players and other non-GPL licensed packages, you’ll have to add to this file. The general format is
type baseuri distribution [component comp2 ...]
Where type is *generally* deb – sometimes deb-src indicating that the repository contains .deb files that are either pre-complied (deb) or are source packages (deb-src).

Make sure you know what the repositories are before you add them! If you add a rogue repository, signatures are not going to help you – they’ll all verify!

Once your sources.list is updated, you can generally leave it alone unless you want to switch to a new version of debian/ubuntu/etc.

On a regular basis, you need to run “apt-get update” with root privileges. This will update the list of packages that have been updated on the repositories. “apt-get upgrade” will just go ahead and upgrade everything for you – which is the easiest option, but sometimes, not what you want. “apt-get upgrade -u -s” will tell you what’s going to be upgraded, but not actually do anything. If you want to upgrade some things, but not others, you’re kinda stuck using “apt-get install package-name” for each individual package. It’s not the best solution, but you can hold a package with dpkg: “echo package-name hold | dpkg –set-selections” and it will *never* be updated.

In general, “apt-get update” followed by an “apt-get upgrade” will get you updated to the latest packages and, hopefully, less vulnerable to attacks and exploits.

As more companies begin to take security seriously budgeting for pen tests, equipment, etc. often the human element of security falls through the cracks. As shown at the Defcon competition, all the locks, both physical and network based, can’t stop an attacker if an employee ushers her through the door.

The Social Engineering Competition was put on by Social-Engineer.org which is an excellent place to learn more about social engineering. Don’t let a lack of employee awareness of social engineering attack vectors undermine your security program.