Last week I had the privilege to attend a tour of the HP SmartHome. A model of a residential building in the middle of the parking lot at HP’s campus in Cupertino represents what some might view as the home of the future. But it is the reality today. It demonstrates HP’s vision of how technology is about to become something more than just an integral part of everyone’s everyday life.

The main idea behind the smart home is dependent on the cloud computing concept, where a consumer’s profile exists in the cloud with all of her data that includes preferences, family photo albums, favorite movie collections and so on. That way all the various devices that the consumer possesses can be easily synchronized through the cloud simply by way of authenticating the user to her profile. This scheme allows the profile to simply follow the consumer when she goes home from work or steps from the living room into the bedroom. And of course, all the devices are now going to be online. And not just computers and TVs, but also printers, alarm clocks, digital photo frames, as well as all the kitchen appliances.

As we were walking from one room to the next and joking about being able to remotely raise the temperature in the oven to be too high in order to cause fire in the house and therefore receive a payment from the home insurance company, I kept thinking about all the possible ways such system can be abused. I can see the same problems and questions arising again as those that did with e-voting and medical devices. How do we protect data stored in the cloud? How do we provide good authentication schemes for distinguishing between legitimate users and attackers? At which point should the system take control in its hands in order to avoid accidents?

Smart home is an example of many cool ideas people have about what we can do with modern technology, but in more and more cases, security and privacy are turning out to be the limiting factor. As we are entering this new technological era, we should keep in mind that software security is not limited to protecting websites or credit card numbers. It's about realizing the potential of information technology. And our job as security practitioners is to help with that and prevent catastrophes caused by technology, like the one that happened at Rutgers, from happening.

The MacArthur Foundation announced its 2010 grant recipients. These fellowships are popularly known as Genius Awards, though no recipient would refer to herself as such. Such luminaries as author David Foster Wallace and mathematician Terence Tao have won this award.

This year the MacArthur Foundation recognized Dawn Song, Computer Security Specialist. As Computer Security Specialists ourselves, we at Fortify are thrilled to see one of our own lauded in this way. Congratulations Professor Dawn Song!

This is the first time the the MacArthur Fellowship's thirty-year history that a recipient's area of principal focus is computer security. This certainly testifies to the prolific Prof. Song and the quality of her work. It speaks highly also to the maturity and importance of this field. Let us ride the swell of Dr. Song's recent award to develop and share good security practices.

Fascinating article on internal security threats specifically around the theft of intellectual property. Well worth the read.

As an intern at Fortify this past summer, I researched analysis techniques for Objective-C and potential security vulnerabilities in iOS (iPhone, iPod Touch, iPad) applications. In this blog post I discuss recent attacks against the iOS platform and note some parallels to older attacks. In my next post, I'll discuss what a attack at the application layer of iOS might look like.

First, I'd like to discuss some articles I've been seeing in the news recently regarding mobile security. There have been a number of articles about "new mobile threats" and "mobile malware," but the attacks described are simply applications that have additional malicious functionality beyond the purpose they claim to the user. This is the exact same type of attack as 10 years ago when downloading a dancing smiley cursor would also give you pop-up ads. When you download a program, whether it be to your desktop or to your phone, there's a possibility that it may have malicious functionality. This type of problem is as old as computers.

Most public attacks aimed at iOS focus on attacking the platform itself or on stealing private data, with the former representing a vast majority. For a glimpse into attacks on the iOS platform, you can get an idea by reviewing the bugs fixed in iOS 4.0. Many of the bugs are from libraries used by iOS, with a large number being in Safari and Webkit. As for privacy, the main public attacks have been from malicious apps that actively steal personal data or legitimate apps that accidentally leave sensitive information in places where unintended agents may access it.

What interests me about these attack trends on iOS so far is that almost no (public) attack has been at the application layer - they've all been attacking the underlying OS or attacking the storage of sensitive data. It's like everyone has been attacking Apache or other programs running on a web server, but no one's been trying to hack the website itself. I think we can expect to see more attacks aimed at iOS applications themselves.

The solutions that SRG has devised for Android's security flaws align with Android's security model. With Android, the developer bears the security onus. In the mobile arena this burden is particularly weighty.

Android allows a user to write data to "external storage". External storage includes removable storage media like an SD card and internal storage. Characterize external storage by what it allows, rather than by where it's located. These files are world-readable, they can be modified in USB mass storage mode, and we're explicitly informed "there's no security enforced upon files you save to external storage".

External storage users claim this is appropriate for large non-private data sets, like ringtones or wallpapers. Clearly it is inappropriate for the password used by your mobile banking application. Consider your organization's confidential information, which you received via corporate e-mail on your enterprise-supported Android phone. Such data should not reside in external storage. Fortify's solution alerts the software developer when the application could send your privileged information to this unprivileged place. When sensitive data never reaches unsecured storage, the threat of data theft as described earlier diminishes.

A malicious application on your mobile device will run roughshod over and across your device's software, as it would on your desktop machine. Android provides a mechanism to pen malicious applications, but fails to exercise it. Android demands that an application request permissions at install-time. The user can install or not based on these requested permissions. Certainly a wallpaper program should not request text messaging permission. These promiscuous applications exist. Fortify's solution advises the developer that dangerous permissions are requested, so that developers can create software with a least-permissive set.

For the first time, Fortify's Security Research Group investigated platforms and applications in the mobile space. In an upcoming post, SRG summer intern turned Ph.D. candidate Clint Gibler will detail his foray into iOS. Here we consider general security issues with mobile. We will go on to discuss how these vulnerabilities manifest in Google's Android operating system and applications.

The foremost security flaw with mobile is that you will lose your hardware. You may lose it to theft, you may hand your phone to a nefarious airport personnel for a few minutes as you walk through the metal detector. Moving away from the sinister side of the spectrum, you may inadvertently leave your phone in a bar. You may innocently recycle your phone when you upgrade to the newer model. Regardless of scenario, losing control of your multi-hundred dollar hardware hands over access to gigabytes of your valuable data: your contacts, your stored passwords, sensitive documents riding along as e-mail attachments.

We acknowledge this problem is endemic to mobile. Any data storage platform is a target for theft: a desktop machine, a laptop, thumb drive, or smartphone; even a manila folder. The risk of loss grows as the device size shrinks. Also, the target's value increases in proportion to its capacity. Thirdly, as a device performs more functions, there exist more types of information on it. A mobile phone contains a list of phone numbers, but a web-enabled mobile computing platform can contain this and bank account information and sensitive documents. Hence we believe that a mobile device like an Android-enabled phone lives in an attacker's sweet spot.

No software solution will prevent losing your phone. Fortify's Security Research Group addressed the resultant data loss by ensuring that sensitive data is not written to an unprotected location in Android. As your phone gains more of the functionality of you computer, you must protect it as such. For example, Android provides full support for SQLite databases that an application may use for structured storage. Mostly full, that is; SQLite mostly mitigates your fears of SQL injection, mostly. Analogous to your desktop, your mobile platform opens itself to attack through its software. These security issues - data loss and malware - exist for the Android platform.

Turns out that your average Joe wants technology convenience more than he wants privacy. Make mine a double. If I can trade a little privacy for sensors in the roadways that allow my car to drive me to work hands free, count me in. Come to think of it, I can't think of a single technological advance that didn't involve some privacy concession.

Speaking of conceding privacy, I'll be in the big apple (NYC) on the 30th for two days if you want to get together and talk security, Fortify or software development. You can reach me at jherrington at fortify dot com.

On Sunday September 5, the New York Times printed an article about password strength. I have mixed feelings about this article. On the one hand, publication in a widely-circulated periodical brings application security issues to general audience. However the analysis in the NYT piece lacks the depth of a security publication. Security professionals are obliged to provide that depth. Consider the theses of the Times' piece, their destructive implications, and how we can guide the conversation to the benefit of users.

By referring to Amazon, PayPal, and Fidelity's websites, the Times insinuates that since a simple password policy is good enough for these guys, it ought to be for everyone. But this obscures the fact that these corporations' simple password policies are just one element of multi-faceted information security infrastructure. If your information security policy is no more than your password policy, your system is in danger. Effective security policy is multi-layered; no single factor will adequately harden the target.

Most of us do not set security policy in the organization; we merely abide. In 2009, Slate Magazine offered salient password creation guidance. Create your password out of a memorable pass-phrase. You might know that I'm a rabid Abba fan, but that won't help you or your password-cracking software deduce Dqy&so17
Dancing queen, young and sweet only seventeen...

2. Complicated password policies do not provide security. A second thesis of the NYT piece avers that password policies provide a false sense of security. False because a password will not protect against some more onerous threats. To evaluate this claim, one must consider the threat highlighted by the Times: a key-logger. Key-logging software on your machine will take your password, your bank account number, your mother's maiden name, and your best friend's e-mail address. Perhaps anti-virus software can detect this malicious program, though I've not found a security expert willing to risk her social security number on an anti-virus suite.

I acknowledge that this is a damning, damaging attack; as such it makes for good copy. A strong password would not stop a key-logger, nor would a dictionary password. Then again, multi-factor authentication, identity-based cryptography, and military-grade command and control would be ineffective. A key-logger is an infallible scribe recording each tap and click. Mentioning this omniscient, omnipresent demon obscures the discussion of passwords entirely. Security policy should prevent a key-logger from landing. A most conservative approach would restrict software downloads. But this circles back to Don Norman's criticism that security policy hampers usability to the point that users ignore the policy.

Amazing article on Stuxnet, a piece of malware so complex that it's taken four months just to decipher it's purpose. Which turns out to be... attacking an Iranian nuclear power plant. So this piece of malware operating in the virtual world is intended to destroy a physical plant in the real world. Methinks we will be seeing more of this type of thing.

Last week I wrote about the SQL Injection potential in Rails. The conclusion there was to write ActiveRecord code the Rails way and everything will turn out alright. To continue on that theme I'm going to take a look at how use ActiveRecord the right way to impose limits on data visibility.

Take the schema below as an example:

Here we have two tables; users and groups. A user owns an asset and should only be able to see assets they own. Simple enough. The ActiveRecord code for the basics is shown below:

require 'rubygems'
require 'active_record'
 
ActiveRecord::Base.establish_connection(
	  :adapter  => 'mysql', :database => 'assets',
	  :username => 'root', :password => '',
	  :host     => 'localhost' )
ActiveRecord::Base.logger = Logger.new(STDOUT)

class User < ActiveRecord::Base
  has_many :assets
end

class Asset < ActiveRecord::Base
  belongs_to :user
end

So now I have a User and an Asset class that wraps the table. Just to make sure it's working I first get all of the users, and the user named 'Jack' with the good code below:

# Good
p User.find(:all)
print "\n"

# Good
p User.find_by_name('jack')
print "\n"

This works, so now I can demonstrate how to find the assets for just me in the next code block:

# Good
User.find_by_name('jack').assets.each { |gi| p gi }
print "\n"

ActiveRecord automatically does the user_id restriction for me on the groups table like so:

SELECT * FROM `users` WHERE (`users`.`name` = 'jack') LIMIT 1
SELECT * FROM `assets` WHERE (`assets`.user_id = 1) 

So I didn't have to do any of the ID magic. I just tell ActiveRecord that a user has many assets and that assets belong to users and it does all the rest.

The same thing happens when I get the user associated with a particular asset like so:

# Good
p Asset.find(1).user
print "\n"

ActiveRecord then generates this code:

SELECT * FROM `assets` WHERE (`assets`.`id` = 1)
SELECT * FROM `users` WHERE (`users`.`id` = 1)

And once again, I don't have to do any of the ID magic work.

If you don't use has_many, has_one, belongs_to or any of that you will end up writing code like this:

# Bad
p Asset.find_all_by_user_id( 1 )
print "\n"

In this case I'm using a find on asset, but I'm specifying a value for user_id. You don't need to do that. Just get the user object then use it's assets member variable.

The same kind of issue is in this code:

# Bad
p Asset.find( :all, :conditions => [ 'user_id=?', 1 ] )
print "\n"

Again, we don't need to go that far with ActiveRecord. Let it do the work for us.

Here is another example where I use the user_id on an Asset record to do a find on the user.

# Bad
p User.find( Asset.find( 1 ).user_id )
print "\n"

The issue with all of the bad code is that I'm doing too much and not letting ActiveRecord do what it does best. And when I do all the work there is a potential that I might forget to put in the restrictions, which might end up giving one user access to the assets of another.

ActiveRecord has a very powerful model system. When it's used appropriately it will enforce data visibility restrictions for you.