As some of you may have noticed, Google has received some heat the last couple of weeks due to claims that they intercepted private data from open wifi-networks when driving around to complete Google Street View coverage. One of the many articles on this subject can be found here: http://www.computerworld.com/s/article/9176810/Google_stops_sniffing_Wi_Fi_data_after_privacy_gaffe

First off: I am very much against any form of privacy infringement and believe quite strongly that most forms of proactive surveillance against non-criminals are futile at best and damaging for national security at worst. However this whole case is just somewhat ridiculous.

Yes, Google made a mistake in not disabling that specific piece of software, but calling the data they gathered private is a bit of a joke. What they gathered was data sent unencrypted over a public network. If you’re sending confidential information over a public network unencrypted, Google stealing your deep-dark secrets is the least of your worries. They did it by mistake – many others do it intentionally!

In fact where I’m sitting right now, I can see no less than 7 open wifi-networks. Most are private homes and most of them have, according to Kismet, traffic flowing over them right now. This means that if I wanted to, I could activate software like Kismet or Wireshark and use this to steal every single bit of unencrypted data sent over this network. In fact, I would be able to do this with almost no chance of ever being detected in doing so. Even if the network owners tried to catch me, they most likely would not be able to. That’s simply how easy and risk-free it is.

The reason why I can do this, is because wifi-networks work by transmitting data outward on a given frequency and then let all clients in that network receive all data. It’s then the client’s computer that needs to filter out what was meant for it and what was meant for everyone else. If a computer behaves “nicely” it’ll discard anything not meant for it, but if it’s been put up to intentionally receive everything, you’ve created a so called “sniffer” and all unencrypted data is up for graps.

While software like Wireshark allows you to only “sniff” data sent over the network you’re connected to, Kismet let’s you “sniff” from any network without ever connecting to that network. This effectively makes you completely invisible to the network owners, so they have no way of knowing, that you’re stealing everything they send.

Sadly, most users are completely oblivious to these facts and use open networks as if they we’re their home networks. And sadly in some cases they even are (as was the case with most of the 7 networks here). So effectively, when Google was driving around gathering private data from open wifi-networks, they weren’t really “sniffing” because they had no intention of gathering that data. The users on those networks were however shouting every single bit of so called “private” information in all directions, forcing Google wifi-analysis software to capture and save it.

Now, to be fair: Google weren’t really being smart here and should not have captured data sent over unencrypted networks. It was a bad move and while they didn’t intend to do so, it probably still didn’t give them a boost in their reputation!

That being said, I must however still say, that the real problem here is the user and the open networks. If you don’t want your data to be scooped up by Google, don’t send it unencrypted over an open network. Chances are someone far worse than Google is listening in – especially if it’s a public network near train stations or the like. Sending data over a open wifi-network is, for all intents and purposes, the equivalent of shouting the same information out your office window.

Back in April 2010 we published a blog post describing the secure way of working from open wifi-networks – We recommend you read up on that and use the techniques mentioned there in order to keep private data private in the future.

Have you ever been on the road towards a meeting or a vacation, and then just suddenly stumbled upon an open network while waiting for a plane or drinking a cup of coffee? Most people probably have..

And have you even been a bit too tempted and logged onto this open network? Again, most probably have.

Now, have you then started working while on this network and directly sent corporate information or handled information on your corporate systems? Sadly, many have and if you’re one of them: Read on! Using open networks directly for sensitive data (like corporate data) is a big security no-no!

So why would this be a problem? Isn’t it just free internet for the masses? Well, yes and no. Yes it’s probably a network you are completely free to use. It might even be a network owned by the office building, hotel, airport or which ever company you’re at. But due to the way wifi-networks are designed, everything you send over this network is completely public. Every person, on the network or simply in the vicinity, can easily set up a simple network scanner like Wireshark or Kismet and directly save all the information you send over this network, including all e-mails, websites you visit, data you send to websites, data you receive – plain and simply everything! And you have no way of detecting this! None what so ever! There is absolutely no way to check for eavesdroppers on an open unencrypted network.

To add insult to injury, eavesdropping on a network is extremely easy to do and there are several easy to use tools out there that hordes of 15 year old script kiddies love to use to steal as much information as they possibly can – for no other reason than: They can!

So are we advocating not using public open wifi-networks? No, not at all – you just need to use them correctly!

You can look at it like this: A public open wifi-network gives you a gateway on which you can build a connection to your workplace and work from there. How do you do this? Well basically there are several solutions here:

• Make the network encrypted.
  Well normally you won’t have the option of doing this, but in most cases it is simply better to keep smaller networks encrypted and then only use encrypted networks. Preferably using WPA2-PSK or WPA-Enterprise as encryption schemes. This is however most likely not a possible solution!
• Use a VPN connection
  A VPN (Virtual Private Network) is a technology with which you can remotely connect to your organization’s network in a completely encrypted manner. It is by far the most transparently secure solution available and is generally the one we would suggest to companies wanting their employees to be mobile always.
  There are several VPN solutions available out there, including big corporate solutions from companies like Cisco and open source solutions like OpenVPN.
• Access resources with SSL/TLS
  While VPN applies to all network traffic sent from your computer, there is also the other option of encrypting critical parts of your work like e-mail, FTP access, critical websites etc. There are protocols to support this for almost all the different kinds of traffic including: POP3S and IMAPS for email, SFTP for FTP and HTTPS for websites.
  Using this solution may in many ways be simpler, but it assumes you know beforehand every place from which you will be needing critical information. It also puts a considerable extra security concern onto the individual employee, since this person now has to deduce whether or not the given communication he/she is doing at the moment is secure or not. Using VPN, these concerns go away in most cases.
• Remote desktop solutions
  Another option, that’s somewhat similar to the VPN option, is to have the employee make a secure connection to a server at the workplace and from there open up a terminal service running another computer remotely. Solutions like this are available in many forms like VNC, RDP and proprietary solutions from companies like Citrix. This gives the employee a remote view of his/her workstation desktop even though he/she is no way near the actual office and, most importantly, it makes it possible for him/her to work securely from any network.

So you can look at it like this: If you’re not doing any of the above, you have a problem and should take it up with your company in order to get a security policy on the matter and making it safe for the company to work from anywhere! Mobility is one of the top priorities in business these days, and you really want to use the opportunities laid before you well, without screwing yourself because of bad security.

So remember: Public open networks aren’t bad, but you need to keep your assets safe while using them!

As we’ve covered in an earlier blogpost (http://blog.aconiac.com/2009/07/29/ruby-on-rails-security-guide/) OWASP is an organization working to improve web application security in the entire world, by means of a whole bunch of different free projects for developers, security professionals and end users.

A few weeks ago, OWASP released a guide/article with the title “Secure Application Development on Facebook”,  basically giving an outline of the security concerns involved in Facebook App development and how to make sure your application is sufficiently secure.

The guide/article can be found here: http://www.owasp.org/index.php/Facebook. The document is mainly designed for Facebook App developers, but can also be useful for decision makers wanting to understand the security architecture on Facebook (however certain sections should probably be skipped).

We highly recommend any company interested in Facebook Apps to read the guide from start to finish, and make it mandatory training for all Facebook related developers.

This is just one of many wonderful OWASP projects and in future blog posts we will look at some of the other great tools that are available to you, completely free of charge. If for some reason you don’t want to wait for these future blog posts, you can also just take a peak the the available projects straight away at: http://www.owasp.org/index.php/Category:OWASP_Project

As is sadly often the case, well-meaning newcomers to programming take on the newest and/or most popular programming language/framework available. And as you might suspect, they usually get it wrong and make every design and security mistake possible along the way!

This is a trend that we’ve seen with pretty much every popular programming language out there – like for example PHP, which sadly still holds the record for most insecure websites written in the language.

One very popular web framework these days is Ruby on Rails, created by the very talented 29 year old Danish guy David Heinemeier Hansson. It uses a Model-View-Controller construction and emphasizes good design by such principles as DRY (Don’t Repeat Yourself). By all means it’s a very good web framework! But as with PHP, a lot of newcomers get it wrong. Either by not following the Ruby on Rails conventions or by ignoring security!

Now, we’re not here to teach you about design. If you want to learn more about proper software design, a good place to start is simply your local library. Look for books on topics like Design Patterns, Software Engineering, Extreme Programming, Test Driven Development and Agile Software Development.

However what we do want to teach you about, is proper security in Ruby on Rails! Luckily, we don’t have to take out extreme amounts of time from the work we need to do, to get you trained in RoR security – instead we can simply refer to the work already done by the OWASP organization. OWASP is an organization working to improve web application security in the entire world, by means of a whole bunch of different projects for developers, security professionals and end users. One of these projects is the Ruby on Rails Security Guide V2 project which includes a PDF file detailing the different security concerns and solutions concerning Ruby on Rails development.

If you are going to develop Ruby on Rails applications (or if you’re simply curious) please download the Ruby on Rails Security Guide from OWASP and read it before doing any production deployment of applications.

Note: If you’re too busy to go to the project page on OWASP and find the download link, then here’s a direct download link instead: Download the Security Guide

If you’ve ever programmed anything in PHP before, you’ve probably had situations where you needed to be careful with your scripts to make sure they were secure. (and if you haven’t, you probably have but just haven’t noticed)

Making secure code is often times not as easy as you would hope, and while PHP does provide certain methods to help you in your task, it still lets much of the hassle be up to you as the programmer. This construction, combined with the amount of PHP sites out there, leads to the sad fact that many insecure websites are written in PHP. And while your own website may be totally secure, perhaps because you read guides like PHP Security Guide from PHP Security Consortium, there is absolutely no guarantee hosting users on your hosting server will do the same – so you need to protect yourself!

Protecting your server, and more importantly the users on it, is really a matter of several things. You need to make sure only the services you need are running, you need to secure access routes to the server (ssh, vnc, rdp etc.), you need to put in surveillance and detection systems (Nagios, Tripwire, Snort etc.), you need to make sure the data is backed up at all times, you need a proper firewall and tons of other things. Covering all these topics is way beyond this simple post however, so we’ll only focus on protecting yourself against badly coded PHP-scripts.

If a hosting user has a website on your server, say http://www.example.org/, and on this site he creates some PHP script that loads in a file and displays this in some way. Now this is obviously a stupid example, because when would you actually need this functionality? None the less, including files like this is sadly often times done indirectly, making it possible for an attacker to load in arbitrary files and gain full or partial access to the file content. In this example however we’ll simply look at a scheme like the following:

http://www.example.org/script.php?filename=test.txt

Where this script then loads in the content from test.txt.

This kind of setup is very problematic, because an attacker can easily take the request above and change it to load other files like:

http://www.example.org/script.php?filename=../../../../etc/passwd

http://www.example.org/script.php?filename=../../vhosts/someothersite.com/secretfile.php

Where the first one loads the password file on the server (it actually only includes usernames, passwords are in another file – but you get the point) and the second one could be perhaps a configuration file for another hosting user’s blog. This way the attacker could gain access to a complete list of users and some login information for another customer.

Both these situations are obviously unacceptable, and while you can’t protect your users from themselves (at least not easily), you can protect your good users from your more reckless users.

One way of doing this is by utilizing what’s called a chroot. Chrooting basically means taking an application and forcing it to do it’s work solely within a given directory, so that i.e. Apache was only allowed to function inside “/chroot/apache” and nowhere else. This prevents websites running on Apache from reading (and writing) files outside this chroot, so that an attacker can’t use the above attack to read the password file. Setting up such chroots aren’t always that easy, since everything Apache uses during runtime needs to be available in the chroot. One project has however attempted to make chrooting Apache much easier. This project is the Web Application Firewall Mod-Security, which can be found here. They use the so called SecChroot option to easily chroot your Apache.

Chrooting doesn’t however prevent a site in the chroot from reading data in another site stored in the same chroot. To prevent this kind of attack, you’d have to logically separate each running virtual host, by either setting up a dedicated Apache chroot for each virtual host (a bad solution) or use something called suPHP. By means of suPHP, which can be found here, we can make Apache run PHP scripts under the permissions of the owners of the scripts, instead of the normal Apache user which is shared between all virtual hosts. By doing this, we effectively make each virtual host able to only read/write files in its own directory and not spy on other virtual hosts data (assuming these have set correct permissions).

But what if we don’t trust this is enough? What if we want to be completely sure, that even if users set wrong permissions, a given user could still never read or write in another users virtual host? This can be accomplished by means of the php open_basedir option. The open_basedir option can be used to control in which directory the PHP scripts of a virtual host can work. This effectively means we’re actually chrooting the PHP scripts! The way you do this, is that you open up your virtual host configuration (which is probably stored somewhere like “/etc/apache2/vhosts/somevhostcom.conf”) and you then add the following within the <VirtualHost></VirtualHost> pair:

php_admin_value open_basedir /var/chroot/apache/vhosts/somevhost.com

Where “/var/chroot/apache/vhosts/somevhost.com” is the location of the virtual host directory. (be aware: If you’ve chrooted Apache, this path needs to be relative to the chroot and not the actual system).

Using open_basedir is not without it’s problems though. By making the PHP scripts run in what is effectively a chroot, they can’t i.e. write to the /tmp directory, which basically means file uploads won’t work. Be aware that chrooting in general can often lead to these types of issues, which is also why many server administrators just simply choose to take the risk and run Apache without chrooting.

Last but not least you can also use Mod-Security as what it was created as – a Web Application Firewall. A Web Application Firewall is a software firewall placed onto Apache, which then uses a complicated rule set to analyze traffic to the server and identify what kind of traffic is an attack and what is just normal use. These rules however have to be written, at least to some extent, manually and there are issues regarding making rules that catch illegal behavior but never stops legal requests – usually you have to accept some level of false-positives in attack detection if you want to be as secure as you can be.

That’s it! We hope you’ve become a bit more informed now and can get on with making your server secure against bad php scripts. Until next time – Keep safe!

NOTE: This is a technical post regarding Apache on Linux with support for Ruby on Rails. Basic understanding of these concepts is necessary!

Normally you want to make sure your server doesn’t give out any information about service versions, however mod_rails doesn’t provide any easy way of doing this within the module itself. There is however a fairly easy solution. Simply use mod_headers to remove the headers in Apache.

So how is it done? Very simple, just enable the module mod_headers and add the snippet below to httpd.conf or another included configuration file in Apache. Both actions have to be done as root of course.

Enable the mod_headers module (This example is Linux Debian – it might be different for your system)

# cd /etc/apache2/mods-available/
# a2enmod headers

Add these lines to httpd.conf

Header always unset "X-Powered-By"
Header always unset "X-Runtime"

Restart the Apache server (Again – this is Debian! It might be different for you)

# apache2ctl restart

And there you go. Try making e.g. a Nikto scan on the server and see if the headers aren’t there any more.