As we make the push toward releasing the platform that I'm working on we've installed exception_notification in our Rails app. With the increased visibility of all the exceptions it became apparent quite quickly that there were numerous hits against the server from automated vulnerability scanners. These attempts were causing routing errors as they looked for paths like '/user/soapCaller.bs' – thankfully not targeting Rails applications. 

The arrival of this sort of scan was not particularly surprising to me as I've seen similar scans in the past. I've even actively dabbled in some security research by running a few honeypot projects, I digress.

Even though these scans usually go after large installations such as WordPress, Drupal, Joomla and phpMyAdmin, it isn't stupid to take it as a reminder to keep up to date on security vulnerabilities. In the case of Ruby on Rails the starting point would be the rubyonrails-security google group and the Ruby on Rails blog. 

Another great resource is Rails Inside. Rails Inside usually picks up any serious flaws and relays them to the community. In addition to this, they follow new releases of popular plugins/gems that may form part of your app. The site provides an important service because keeping up-to-date is a good way of reducing the risk of being caught by a vulnerability that has been dutifully patched by the maintainer.

The above is certainly not a complete list, so I'd like to hear if there are any other rails/ruby security resources that you find useful. 

I don’t think that I’ve had this much adrenalin pumping through my system on a Saturday morning in quite a while. My girlfriend signed into her email (as she does most mornings), to discover an email from eBay Live Support asking for a code. She called me over and a few seconds later the email vanished. What happened after that point is a blur of password resets, both her and the would be hacker trying to gain control of the hotmail and through it the eBay account.

There were paranoid moments when passwords wouldn’t work, but in the end she’s still in control of the accounts. Just about every account she owns has now had the password and details changed to help protect it.

It’s intrusive though. How exactly did the attacker break into the account? Not phishing, Cherie is well aware of those type of malicious emails. Guessing the security questions? Maybe.

That raises other concerns though, email addresses become repositories of knowledge for our online lives. Just about every account you sign up for online has to have an email account linked to it, that means many details about your online life are there in fragments. We’ll never know exactly what the hacker had access to (albeit briefly).

I’m personally going to be reviewing all my accounts to make sure that they’re secure, and I’d advise you to do the same.

(And I’m hilarious)

Seems that simple lessons don’t get learned. Don’t get get me wrong, its very hard to protect every aspect against hackers who try to pry they’re way into your site. Storing passwords in plain-text is just dumb though. Even if the passwords for your own site are hashed, the proliferation of storing third party login details (which you could still encrypt with a symmetrical key) is a time bomb.

RockYou is just the latest site on the internet to learn this hard lesson. Supposedly the hacker is one of the good guys, but there is no guarantee that someone else didn’t get the information as well. It’s an argument for doing away with passwords altogether, how long will it be until we can use public/private key authentication with websites. It is now accepted best practice with SSH, since the advent of widespread SSH bruteforcing.

Private key authentication solves a lot of the problems with websites storing password information, the hacker would have gained nothing besides the ability to verify users were who they claimed to be.

A huge deal has been made of the Terms of Service for Google Accounts and Google Chrome. Slashdot, Ars Technica and a host of bloggers jumping on the bandwagon to pimp their blogs. And the cause a few sentences in the Terms of Service for Google Accounts, which apparently got copied to Google Chrome (Which has since been corrected). Here is the offending passage (as copied to slashdot):

“By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt,
modify, translate, publish, publicly perform, publicly display and distribute any content which you submit, post or display on or through, the services. This license is for the sole purpose of enabling Google to display, distribute and promote the services and may be revoked for certain services as defined in the additional terms of those services.”

Scary? Not really, as far as Google Chrome goes its actually a mistake. Someone at Google didn’t read the Google Accounts ToS closely enough when they copied and pasted
it. The offending section has now been changed:

11. Content license from you

11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services.

Many people are also concerned about the above as it relates to Google Accounts. Let me debunk those concerns, first by providing the whole section of the ToS:

11. Content licence from you

11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services. By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive licence to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services. This licence is for the sole purpose of enabling Google to display,distribute and promote the Services and may be revoked for certain Services as defined in the Additional Terms of those Services.

11.2 You agree that this licence includes a right for Google to make such Content available to other companies, organizations or individuals with whom Google has relationships for the provision of syndicated services, and to use such Content in connection with the provision of those services.

11.3 You understand that Google, in performing the required technical steps to provide the Services to our users, may (a) transmit or distribute your Content over various public networks and in various media; and (b) make such changes to your Content as are necessary to conform and adapt that Content to the technical requirements of connecting networks, devices, services or media. You agree that this licence shall permit Google to take these actions.

11.4 You confirm and warrant to Google that you have all the rights, power and authority necessary to grant the above licence.

and then with the following from Googles own FAQ:

Privacy and security: Understanding section 11.1 of our Terms of Service

We’ve received questions over time about the meaning of section 11.1 of our Terms of Service. We realize that or those not familiar with legal agreements for services that use the Internet, these terms can look confusing, or even frightening.

The first thing to understand is that this language doesn’t give Google ownership rights to your data. You, and you alone, own your content. Whether you wish to keep your content totally private, or share it with the world, that’s your choice.

However, in order to honor this choice, Google Docs needs permission to display your content as you see fit. This is what we mean by a “license to reproduce.” We
need to ensure that when you click the “Publish document” button, or use the “Invite collaborators” option, we have the license to carry out your wishes. It
is this agreement, between Google Docs and you, the user, that section 11.1 of our Terms of Service reflects.

So firstly the license that you grant google is for the sole purpose of technically performing ‘publishing’ and ‘collaborating’ on content, and secondly The Terms of Service go on to talk about terminating the agreement. Honestly its all legal speak, Google could get away with a lot if it wanted to, with or without license. But they market themselves as not being evil, stepping away from that statement is not in their best interest; people have long memories. So sure be a little bit cautious when you use these wonderful Web 2.0 services that google and others provide, but please spare me the overhype. If there is a problem then contact the people that can fix it and a wait for a response.

I’ve been going along mostly unaware of the fact that the internet is currently experiencing a nasty spate of SQL injection attacks. These attacks are being used to infect visitors to otherwise harmless and friendly websites. They’re advanced and complicated attacks that a few years ago the world had never really experienced, thats not the case any more. It is an increasing reality that viruses and worms are no longer the province of bored uni students, but rather done by what can only be described as a technologically aware organised crime. The site I happened to run across the problem at, finally took the site offline and cleaned the fields that had been ‘infected’, and I would hope that they’ve also taken steps to solve the problem.

I’m going to build some more information up on the technical aspects of this attack. So for the moment this is a place holder. I’ll be building up some more information over the next few days.

I want to quickly run you through the pitfalls of using java as a programming language when it comes to the security of your proprietary source code. One of the problems with Java is the relative ease with which you can reverse engineer the source code. In fact there are numerous tools out there which will very simply and quickly take your project and turn it into a VERY readable document. For the purpose of instruction we will first decompile the example project, comparing the original source with what comes out the other end.

We will repeat this process (if possible with the techniques that can be used to protect your source code).

The Jad Decompiler + Front End Plus

As mentioned above there are plenty of available decompilers, however JAD is a free and open source alternative that is perhaps the most popular option out there. Coupled with Front End Plus, a GUI that is designed to use JAD, you can very easily open and decompile the Java source.

This is a decompile of my own Arms Conversion program, as you can see, while you may have to do a little work if you wished this code to recompile, the intent of can be seen very clearly.

Obfuscation

Obfuscating the source code is one method that is often used to protect Java code. It refers to deliberately making the code harder to read. Rather than a cracker getting back a function called IDoSomethingCool (String name) … they instead might get something back like dadaba3 (String adabc9989).

This doesn’t stop the cracker from reading the code, nor from it working if they chose to recompile it. However it does make it MUCH more difficult to determine the intent of the code. Are the naming conventions that programmers use to determine what information is being stored/parsed/manipulated

I should be clear that this is far from a full proof solution. With time and dedication it is still possible to rebuild the original intent. However Obfuscation is a big step towards making it a waste of time (it may cost less to just write the application from scratch).

There are plenty of tools available that can be used to obfuscate the code.

Native Compilation

By far the best option for protecting the source code is the ability to natively compile the application. While there are potential issues to be addressed in order to implement native compilation it has the benefit of making the reverse engineering infinitely more difficult.

While NO application is truly immune to reverse engineering, going from compiled code back to useable source code requires a very specialized ability, and a depth of knowledge about computer programmers that is possessed by few.

Native code compilation is discussed in more detail in another document, which deals with additional features that are available, and also the potential problems with natively compiling your applications.

There are supposedly 10 laws of security. Laws that are a firm basis for understanding computer security. They’re obviously not the be all and end all of computing security, but for beginners and those that aren’t going to focus on security they’re an important start.

The Ten Immutable Laws of Security

Microsoft’s Security Response Center Manager, Scott Culp, as a part of his job produced a list He calls “The Ten Immutable Laws of Security.”

They are:

1. If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore.
2. If a bad guy can alter the operating system on your computer, it’s not your computer anymore.
3. If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore.
4. If you allow a bad guy to upload programs to your Web site, it’s not your Web site any more.
5. Weak passwords trump strong security.
6. A machine is only as secure as the administrator is trustworthy.
7. Encrypted data is only as secure as the decryption key.
8. An out-of-date virus scanner is only marginally better than no virus scanner at all.
9. Absolute anonymity isn’t practical, in real life or on the Web
10. Technology is not a panacea.

Even without further explanation (which is available from here) it is a fairly straight forward and common sense list of laws.

Law 0

The fact is that these laws don’t go far enough towards describing the problems that are faced by everyday users on the internet. Security people often forget that its not just big companies that are the target of attacks; they may indeed be the target of more personalized attacks

1. If you can’t read the source code for your operating system (and applications) then it’s not your computer anymore.

I hate being the open source advocate, but the fact remains that if you and the community can’t get into the source code for auditing and patching purposes then its not your computer its Microsoft’s. You are essentially relying on their good will and the competency of their programmers to protect you against any flaws in the operating system that may let attackers in.

Microsoft has in the recent past finally hopped on the security band wagon, they’re better than they used to be, but its still them against the world, and in practical terms this makes for an impossible situation. The odds are that one of the millions of hackers is going to find it before Microsoft does. Even with their ability to look at the source code they’re still vastly outnumbered.

Open Source

Open Source is not a complete solution to this problem, but its better. The millions of security researchers out there, the developer community and the general public all get the chance to look for flaws in the code. Immediately once it’s discovered a patch is written for it. Unlike a situation where you have to wait for a company to release a patch, you have the ability to patch the problem yourself, its not you against the world though. It’s you and every other technically competent person that uses that particular software against the world.
Yes, hackers have the same opportunity of finding the flaws. But the playing field is more level. Even if they do find a flaw, chances are that it’ll be patched much more quickly than if millions of eyes weren’t looking at the source code.

Open Source vs. the Other Ten

When you look at open source as a solution to the problem above; it puts them in a whole new light. Let’s start with No. 7, not because of the fact that it’s a good number, more the fact that it has long been the belief of the scientific community that closed encryption algorithms are useless.

1. Encrypted data is only as secure as the decryption key.

While this deals with the key that is used to encrypt the data I would go further and say, that encrypted data is only as secure as the Algorithm and Key that is used to encrypt the data. It doesn’t take genius to work out that even if I encrypt my information using my own proprietary method that doesn’t mean that it’s safe. Unless someone else can test my encryption method, and try and break it, I have no way of knowing whether my information is protected by the encryption; because, I have no way of knowing whether my encryption algorithm is sound, or whether there are fatal flaws in my design.
History is littered with examples of this, and if you look closely at companies like RSA you will notice that they post challenges, trying to get people to break their encryption.More importantly if you can’t look at the encryption algorithm and analyse it for yourself, how are you to know that the creator hasn’t put in a backdoor for themselves, or governments to use.

Watching the Watchers

An out-of-date virus scanner is only marginally better than no virus scanner at all.

Nearly everyone that I know, knows to use a virus scanner now, its slightly harder getting them to workout Spyware and AntiSpyware programs, but here’s the twist, if you can’t look at the internals of the anti virus, how do you know that its doing an adequate job of protecting you.
I’m not trying to say you should be using Linux because of the fact that it is less prone to viruses, the fact is that most viruses are written for windows, and if everyone switched to Linux, then those same people would target Linux. It remains to be seen how well Linux would respond to this kind of problem.
What I am saying is the applications that you pay good money for, you subscribe to a service by Symantec or McAfee, and you really have no idea how well you are being protected. The same goes for firewalls, and any other piece of security software that you use to protect your computer. If you can’t look at the internals then you have no idea what the application is really doing.
You can apply this same principal to at least some of the other laws, and in truth it serves to cement the 0^th law in place.

Regarding Patches

It is not often that I have the chance to talk about security, but one of the things that occurred to me in my day to day work is the fact that Microsoft’s move to allow only ‘Genuine’ users to download patches and applications, most notably SP2 and Microsoft AntiSpyware, was a foolish one.
Regardless, of the fact that most if not all of my clients have legal copies of Windows, it is rare that they keep them patched and up to date (I tend to fix this), but it leads me to believe that there is a large number of legal windows users out there that don’t patch their computers properly.
Now, it’s not overly smart of them, but the fact of the matter is that denying patches and other downloads to ‘non genuine’ users, ends up negatively affecting even those with legal copies in a round about way; look at it like this:
the greater the number of unpatched computers on a given network, the more chance that a bad guy/worm will get in.”
This is easy to apply, but what is more important is that it takes into account not just small local networks, but the internet as well. The more unpatched computers that remain on the internet, the more chance that the bad guy will get control of them; and the more computers that are either part of botnets, or infected by viruses the easier it is for it to spread, or the attacker to use the given host as a base for another attack.

A Note on Piracy

I’m not in anyway condoning & supporting piracy, but there comes a point when you need to accept that a problem isn’t going to be solved and make smart moves. Becoming tight and vindictive about piracy only makes the given company *cough*Sony*cough* look bad.
Locking your legitimate users out is bad methodology, and putting so many ‘copy protection’ methods into a given technology that it negatively affects it is not healthy either. Security is important, but it needs to protect the interests of the user not the interests of the greedy Mega Corporation.