Devise Google Authenticator 0.3.3

A couple of weeks back, whilst working on some building some internal management apps, I finally got around to implementing the Devise Google Authenticator gem into a rails app outside of its own testing app. During this process I realised that I hadn’t correctly updated some of the extension’s code to properly work with the Devise 2.0 release, in particular the changes to the migration schema. A few amendments, a push or two and version 0.3.3 was now available.

Looking back over the process I’ve certainly learned a lot about Ruby, Rails and Devise, plus the whole Ruby Gems eco-system. What’s surprising though, is the number of people out there who appear to be using the gem. At a high level the breakdown is as follows:

So far though, we’ve only had a few queries come in. But, to try and capture them in a more appropriate place I’ve started a Google Groups which, if you wish, you can sign up to and post queries. Or, if it’s easier, just hit us up on twitter: @xntrik or @asteriskinfosec.

Cheers!

Application Security: Your First Steps

One of the areas of information security that Asterisk has a keen interest and involvement in is that of Application Security. Whilst security of your infrastructure, in particular the perimeter and end-points, has been a focus point for a number of years now most of the important information stored by your business doesn’t usually reside in those locations. Sure, transient remnants of information are always likely to exist on your end-points, but centralised storage and management of sensitive information has been a central enabler for IT since the concept of client/server architecture began. For most people involved in information security, or even information technology, this is not news at all. In fact, it’s been the message that organisations like OWASP have been hammering on about for over a decade now. Unfortunately traditional firewalls and anti-virus don’t really help you when it comes to assuring the security of your applications, especially your web-applications, on the contrary your firewalls are usually configured to explicitly allow access to your web-applications, I mean that’s what they’re for.

As part of our involvement with the application security space we participate in conferences and events focused on the security of applications, unfortunately, these events always struggle to draw in the people that would really benefit from this knowledge. I’m talking about the masses of people who actually run their businesses online, or the people that rely on the Internet for their commerce, and there’s lots of us (yes us too, we utilise various online services for the management of our business too).

So where do they start? Can they talk to their IT guy? Can they talk to their AV vendor? If there were an easy solution to securing applications, we would have all done it already, right? And if you’re in the business of relying on your staff, or contracted staff, to build applications for you, then trust us, this is definitely an issue that you should be aware of. If you haven’t had an opportunity to read Verizon’s Data Breach Investigations Report for 2012 then you should get your hands on it [pdf] (Or a really good high level summary can be found over on Securosis). One of the takeaways from the report is the number of breaches where the vector was hacking via web applications. (The recent report indicates that overall 10% of external hacking incidents, leading to breaches, where related to web applications. This statistic increases to 54% when looking at organisations with 1000 or more employees)

Honestly, starting is the simplest bit; it is being aware of the problem. Awareness that a lot of attacks are opportunistic in nature, and that you aren’t necessarily a target, except for the fact you reside in some form on the Internet. The tools and the methods employed by these attackers are not a dark art; they’re relatively simple and widely discussed in the industry and by many ‘above-board’ organisations. One such organisation is OWASP, a not-for-profit worldwide organisation focused on improving the security of application software. And you know how they do it? The publish materials and tools, for free, online. Asterisk is so keen to dedicate itself to this cause that two of our founders are local chapter leaders within OWASP.

If step one is increasing your awareness of just how exposed your applications are online, then step two would be dedicating your morning read to some of OWASP’s materials (If I had to choose a starting point, the latest version of the OWASP Top 10 is as good as any), or better yet, finding out when your next OWASP chapter meeting is and heading on down to say ‘hi’.

Don’t give up hope, and don’t worry, this is going to be the first of many posts on how you can start looking a little closer at the security of your applications.

Checkpoint CCSA Training

The Asterisk team have had a long history with Check Point training (we have certs dating from 1999 to 2012!! .. try not to do the math, we’re not that old), and are really happy to be bringing a course to Perth. We have seen how product training on security technology gives Security Admins at customer sites confidence to deploy new features, and Check Point’s Blade architecture is certainly driving more features and functionality on the gateway.

We are hosting Check Point Security Administrator Training in Perth from the 9th to 11th of May which is open to anyone. This training will be based on Check Point R75, and will cover Security Management, NAT, policy optimisation, back up & recovery and additional topics over the 3 day training. Course objectives can be found here (pdf).

The course is strongly recommended for anyone thinking of doing the CCSA R75 exam.

Course registration info can be found here: Asterisk Information Security Check Point CCSA online version (pdf)

Website defaced? Check your PCs for Malware!

Asterisk were recently called in to assist a Not-for-profit in responding to a website defacement security incident. Initially it was suspected that there must be some vulnerable web application code on the website, perhaps via an un-patched web forum, or old, archived copies of an out of date forum. Of course when you start looking through the web logs and you can’t see anything obvious that’s when you have to widen your net.

So naturally we checked out the FTP logs, and voila, a number of uploads from an IP from Monaco, placing numerous .php files in numerous folders. This IP address logged into the FTP account using the primary FTP account holder’s username, which we knew had a really complicated (read: 12+ characters with a mix of upper, lower and symbols) password. After confirming with the client that they stored these credentials in FTP client software on a few computers, the next avenue of investigation was that they’d had their one of their PCs compromised… and there was the root cause.

Whilst this isn’t that uncommon these days, it’s certainly something to consider when you’re responding to website defacement incidents.

Doing a bit of research now on the IP address you can also see that this attacker went after quite a few sites.. http://www.ipillion.com/ip/193.104.153.63

Integrating Google’s 2nd Factor Authentication with your Rails App

Asterisk is happy to announce the release of their first (beta) Ruby Gem. The “devise_google_authenticator” gem is a Devise Extension that integrates Google’s 2nd Factor Authenticator into Devise’s authentication scheme. It’s not designed to replace the existing password scheme (database_authenticatable), but it’s ideal to provide a second factor authentication mechanism from your smart phone (Android, Blackberry, iOS).

If you are doing any Rails development and have a need for user authentication/authorisation then you should certainly be checking out Devise. From their site:

Devise is a flexible authentication solution for Rails based on Warden. It:

  • Is Rack based;
  • Is a complete MVC solution based on Rails engines;
  • Allows you to have multiple roles (or models/scopes) signed in at the same time;
  • Is based on a modularity concept: use just what you really need.

Lets put together a really simple application.. (I’m assuming you have Ruby 1.9.2, but no other gems available. Also, most of this is following the Rails Guide and the Devise installation process)

Install rails:
$ gem install rails -v 3.2.0 –no-rdoc –no-ri

Create your vanilla app:
$ rails new myapp

Change into your new app:
$ cd myapp

Edit your Gemfile with the following two lines (after gem ‘sqlite3’):
gem ‘devise’, ‘~> 1.5.3’
gem ‘devise_google_authenticator’, ‘0.3.1’

Update your bundle:
$ bundle install

Create some data for your app
$ rails generate scaffold post title body:text

Install Devise:
$ rails generate devise:install

Install Devise Google Authenticator:
$ rails generate devise_google_authenticator:install

Create your user model:
$ rails generate devise User

Add the Devise Google Authenticator scheme:
$ rails generate devise_google_authenticator User

Migrate your database changes:
$ rake db:migrate

Remove the static index page:
$ rm public/index.html

Change the root page (edit your config/routes.rb and add the following below resource :posts):
root :to => ‘posts#index’

Edit your main application controller to require user authentication for all pages (edit app/controllers/application_controller.rb add just after protect_from_forgery) with the following:
before_filter :authenticate_user!

Now start up your app and visit localhost:3000:
$ rails server

After you register your user (after clicking Sign Up), you should be displayed with a QR Code. Simply add this to your Google Authenticator app on your phone, enable the authenticator, close down your browser (to clear your session), revisit the website and after you sign in, you’ll be prompted for your one time password.

Voila!