Today, a friend that I had not chatted with in some time comes online, and sends me this:

My first thought has been “Uhm, why would Mike send me something like this?”. He’s not prone to even send smilies, always very short and to the point. I go to ask him about it, but I then notice he is in do-not-disturb mode, so I cannot even warn him about the now-obvious scam! It seems that phishers and other scum are realizing people fall for email traps less and less, and are attacking other more trustworthy systems. In this case, the attacker is sending a screensaver, most likely loaded with a trojan. Beware of -any- communication, even from friends, that is unusual in timing, behavior or content. Also, beware about being asked for your IM details, and use strong passwords.

What do you do when you have in your hands the best security distribution in the world? Use it! Here is the result of Mati Aharoni’s (aka Muts) impersonation of The Mexican – click the image to view the full video.

Kids, do not try this at home, and if you are using Windows, well…my sincere condolences. While you are at it, check out the home site for BackTrack.

During my investigations that led to the statistics post, I also discovered a serious flaw in the maps management system, which would allow anyone to re-position any FON hotspot and change its address without first logging into the user area.

All that was required was the node’s ID and the hotspot owner’s user ID, both easily obtainable from the public queries that maps.fon.com launches against the database where hotspot data is held, and which I used to gather the statistics. For a determined attacker, it would have been very easy to place every single FON hotspot right in the middle of 1600 Pennsylvania Avenue, Washington DC.

I could have very easily posted about this, but I refrained from doing so for a reason – while I do not work full-time in the IT security industry, I have done quite a bit of consultancy work in the past, related to IT security, particularly in the wireless field. This means that I am fully aware of the industry-approved vulnerability disclosure procedure, which can be explained simply as:

• Document the vulnerability, and inform the company about the fact that you have found it.
• Wait for an initial response, establish contact points, and work a schedule for fixing the issue.
• Work with the company to help them solve the issue.
• Once the issue has been fixed, make a public disclosure on both sides about the vulnerability, giving credit to the person or company that discovered it.

You can find more references to this policy at Microsoft’s Security Response Center, here and here. A PDF from oisafety.org also describes this process in detail. A perfect example on how not to do things is the recent disclosure of a code injection vulnerability, which allowed manipulation of FON’s routers without even having to open them – even though their points are valid, they should have given FON the chance to fix the problem before going public.

In this case, I contacted FON’s support email first September 27th, and received a response on the 29th. This was really generic, only wanting to know about the details, and not acknowledging the normal procedure as I have explained above. On October 2nd, I emailed them again, asking to confirm that they understood the procedure, and on the 3rd they replied that they agreed on following the procedure.

I started compiling the information I had into a working document, but after becoming so frustrated at the attacks received as a result on my post about the statistics, the decision was to simply let the issue go, forget about FON, and concentrate on my own project. A couple of days ago, browsing around for stuff to clean up on the laptop, I came across the half-written report, and decided to finish it and send it to FON support, with CC to Martin, just to close the case. I received a reply today that they have in fact fixed the vulnerability, with a short ‘thanks’ (actually, quoting his email in full: “thanks Mike, i understand its been fixed”) from Martin.

The public acknowledgement of the discovery posted by FON is found in this forum post. Only in the English forums, by a user created apparently for this particular purpose, as this is his first post ever, where it is not likely to draw much attention. This would be fine by me, had not there been the precedent of Martin’s fierce replies to my statistics post, followed by countless attacks by FON’s followers, including an unfortunate incident better left forgotten. What I really cannot understand is that, when I criticize FON, I get such a huge public lashing, whereas when I help them out, I get a three-line remark in a forum where it will go mostly unnoticed. The end result may well be that other vulnerabilities, and it is likely they exist, go unreported.

Whatever the case, this should show those who accused me of unfair, biased attacks on FON that I really just call the shots as I see them, when I smell bullshit, I will point to it, when I see a hole, I will help them fix it – again, IMHO, blogging is not about being or not biased, it is about being ethical and maintaining a set of standards. In my view, it should also prompt Martin to write an apology, but I am not holding my breath. Not that I care much either, what is most important is my work; this is my blog, where I spend part of my spare time, which is not actually that much.

Today we are going to talk about Unix security.  The first topic will be the first security system you run across when using Unix.

[] Password Security

Next we will talk about some of the implications of the networking programs which are available.

[] Networking

We will then talk about what it means to protect a file

[] File Security

After that, we will discuss ways for keeping information even more private should you decide to do so.

[] Encryption

I have no intention on teaching you how to break into a system. Instead, I hope to point out some of the things you should do to make sure that you are not the victim of someone elses attempts to breach security.

———————————————————————-
[] General Overview

UNIX is not a “secure” operating system.  It really wasn’t designed to be one, though.  But, what do we mean by security?  Let’s start by considering several types of security.  There is physical security. This is made up of things like locks on doors, and the Campus Police. For some systems this is sufficient.  For instance, if a computer, and all the terminals which can connect to it are in a locked room, then the system is as secure as the lock on the door is. 

What happens, though, when you add a dialup?  Or a network?  No machine which can be accessed from the outside should be considered secure.   The first line of defense is passwords though.  The idea is to keep people who aren’t supposed to be using the machine from being able to do so.  If they can’t do anything at all, then their not going to be breaking security.  Of course, not all password systems are so great.  It is often possible to obtain passwords by guessing them, or
through various other means.

The last type of security is of particular importance to Athena.  What do you do in an anvironment where lots of people have accounts, but not all these people can be trusted.  You need some way of controlling access to resourses such that people have access to their own files (or other files in certain ciscumstances), and only limited (if any) access to other peoples files.  It is at this level that keeping a system secure becomes a problem because the potential intruder has so many more attacks he can try.

[] Password Security

Let me start by talking about password security.  Under UNIX, passwords are stored in the /etc/passwd file.  This is a publicly readable file, so clearly, something has to be done to protect the passwords.  Passwords are encrypted in such a way that they can not be converted back into the plaintext they were generated from.  When you log in, the system asks you for your password, it then encrypts the password, and compares the encrypted version to what is stored in the /etc/passwd file. 

There are several attacks to breaking this security method.  One approach is brute force.  An attacker tries all possible passwords until he finds the correct one.  This attack is impractical because of the time required. 

Fortunately (for the attacker), most people choose common passwords. There username, their name, or words that are in the dictionary.  In one experiment (described in “Password Security: A Case History” by Robert Morris and Ken Thompson), 3,289 passwords were collected over a along period of time.  Of these,

15 were single ASCII characters
72 were strings of two ASCII characters
464 were strings of three ASCII characters
477 were four alphanumeric characters
706 were five letters either all upper, or all lower case
605 were six all lower case letters

492 appeared in various available dictionaries

A few things have been done to make things more difficult for the attacker.  An encryption algorithm is used that takes a lot of time to run.  This tends to increase the time required to guess passwords. Passwords are also “salted”.

One attack that has been used is to come up with a dictionary of encrypted passwords, and compare the encrypted password in the password file with the encrypted dictionary.  This takes a lot less time per entry than having to encrypt the plaintext word you want to test, and then comparing it to the encrypted password.  Salting a password means that a random number is selected when the password is initially created, and added to the plaintex before it is encrypted.
This random number is then also added to the encrypted password before it is written to the password file.  When a password is checked, the same random number is taken from the encrypted password, appended to the plaintext which is then encrypted, and the result compared with the encrypted password.

Salting the password means that there are now 4096 versions of each password that are possible.  Thus, an attackers dictionary would have to be 4096 times as large.

[] Networking

The availability of remote login and remote execution in a networking environment (as exists with Athena) introduces many new ways to breach system security.  The problem is how to authenticate users across the network without requiring them to enter their password again.  The way this has been accomplished is through the concept of a “safe host”.  A job can log in, or remotely execute commands without a password only if the user is logged in from a “safe account” on a “safe host”.

Networking has presented many other problems for system security, but I do not intend to discuss them at this time.

———-
[] File Security

What does it mean to protect a file?

Under UNIX, there are several fields in the protection of a file.  The first three bits control access to the file by its owner.  The next three define the access by other people in ones group (people in the group that owns the file).  On Athena, most peoples groups are “mit”, so this group field is really just another field for “world”.  The last set of three bits define the access for everyone else.

The bits on a file control read, write, and execute, but one also needs to be concerned with the protection bits on directories.  If someone has write access to a directory, then they can create, and delete files contained in it.   Read access to a directory gives one permission to look at the directory (with ls for example). Execute access conveys permission to connect to the directory and to search it for a file which you know the name of.

It is also important to note that someone with access to the root account can read, or write ANY file on the system regardless of the protection.  Pleople who have this access include Athena staff, some consultants,  some system wizards, and occasionally someone who has managed to break the systems security.  On Charon, certain SIPB member have root access.

When you log in, your .login sets a “umask” which defines the default protection you want to give files you create.  This mask is 3 octal digits defining the bits that you DO NOT want to appear in the protection for the various entities (owner, group, and world). Further, if you have given niether read, nor execute access to a directory, then other users will not be able to access files beneath that directory regardless of the protection of the individual file.

[] Encryption

As you can see, there is no way to keep a file totally secure under UNIX.  Since the file can’t be secure, you may want to use encryption to keep the contents secure.  Currently there is a program called crypt which can be used to encrypt files.  Unfortunately, the algorithm used in crypt has been broken.  In the near future, Athena will be distributing a new algorithm (I believe based on DES) to replace crypt.  This algorithm is believed to be more secure.

In my book, this is plain and simple espionage. There are laws in some countries (also at state level in the U.S.) that govern wiretapping and conversation recording; in some cases, recording as long as you have the consent of one of the parties involved is OK, in others it is just plain illegal. Of course, Google would argue that they do not send the actual sound anywhere, but only a mere derived “signature”. Jim Atkinson’s tscm.com site has some really good information on the subject, as he has been dedicated to hunting down the spies for decades.

All this brings me to a new subject, which is the amount of information that Google may already be collecting about you – personally. Do you have a Gmail account? Do you know about something called Google Analytics? Some of you will have already put two and two toghether (answer is not three). Gmail privacy statement mentions:

Google scans the text of Gmail messages in order to filter spam and detect viruses, just as all major webmail services do. Google also uses this scanning technology to deliver targeted text ads and other related information. This is completely automated and involves no humans.

OK, so they have the contents of every email you send and receive, classified in terms of what sort of things you may buy if they present you with targeted advertising. On the other hand, Google Analytics is a statistics tool widely used by people and companies to track usage of their websites with a great deal of precision. Information collected by Analytics includes the IP addresses of visitors, every action they take, and every navigation path they follow.

Now, combine the two bits of information common to your Gmail account, and somebody.com’s tracking data of your browsing session – the IP address used to send the email, or to browse the site. It can be argued that in many cases, these IP address can be dynamic, or belong to a large organization behind a proxy – but hey, Google is now potentially handling millions of bits of statistical data, so they could eventually learn a great deal about what you do online. Now they only need what you are watching on TV, and your assimilation will be complete. Resistance is futile.

Can anyone say separation of powers? If you are really concerned about your privacy, you probably know what this will do, once placed in your hosts file:

# [Google Inc]
127.0.0.1 www.google-analytics.com
127.0.0.1 ssl.google-analytics.com

If you don’t, then welcome to the era of privacy deprivation..

[Edit: I have changed the post’s title, as it looks like the strike tag was causing problems with indexers…sigh]

The audio is in spanish, but you will get the general idea even if you don’t understand the talk. My oppinion is that they shouldn’t have done this, as connecting to WiFi networks without the owner’s permission is illegal in most countries, Spain included – so they have actually provided potential prosecutors a perfect piece of evidence.

Linux on a plane

Now we could all start making jokes about nmapping the plane, or trying to run Asterisk off a USB drive plugged into the management console, which by the way was accessible to anyone who wandered to the toilet and happened to look left. It had a nice big “Reset all” button too, two USB ports, and a gigabit etherenet RJ45. I just hope they don’t run a kernel with some remote_crash_plane() buffer overflow exploit…

There was plenty to see and do, from conferences as interesting as war-rocketing to an insight into the US-VISIT program, and it’s plans to implement RFID tags into the green visa waivers, or the 2D barcode receipts given out at airports.

I participated in the wardriving events, organised by Thorn, and which consisted of the Running Man and Fox Hunt competitions. Our team was led by Renderman, and we had some backup that put up some noise (fake APs, floods, etc.) to make the contest more interesting.

The Running Man started well, but unfortunately the other team tripped casino security by walking past their booth with a magmount omni antenna on each shoulder, a laptop, several WiFi cards dangling from their belts, a YellowJacket, and other gear – apparently, the IT guys freaked out, and they wanted the contest shut down. After the intervention of Ross and Priest, we were allowed to carry on, but limiting the search area to the venue, and not the whole casino. After the contest resumed, we found the Running Man in around 15 minutes, and won!

The second contest, Fox Hunt, consisted of a hidden WRT54G that was only on for 15 seconds every minute. One was supposed to locate the fox, connect to it, and change the SSID after brute-forcing admin account. 15 seconds to do all that is not a lot! So, our plan was to locate the fox….and make a run with it to a safe place, so we could kill the 15 second timer circuit, reduce the amount of RF leaking out and have a go at changing the SSID. The first part of the plan went well, but then the other team got slightly miffed, called Thorn, who in turn called us to go back to the contest table with the WRT so the other team could also have a go at it.

Interestingly, Thorn had taped the admin password to the bottom of the router, but neither team noticed it! In fact, the other team ended up brute-forcing the AP and changing the SSID. We contested that since when we removed and reapplied power to the AP, the SSID went back to its default, we had in fact won, but Thorn wasn’t having any of it. The contest was a tie, which was decided by the question “Who owns the OID 00:00:00?”, the answer to which is Xerox. We got it wrong, and so we lost. Next year we will be better prepared for sure.

Here are a few pictures from the event:

Thorn and Renderman giving their presentation on the Church of Wifi, with CoWPatty, the WPA rainbow table generator, and the WRT54G mods, which included my WaRThog.

The war-rocketing guys, and their awsome rocket. I wonder how they got that thing past airport security.

The WaRThog on the left, with two more of CoWF’s modified WRT54Gs.

If you used DEFCON’s wireless network to check your email, access your corporate network, etc., but didn’t use any form of security (VPN, SSH…), you are bound to be in the Wall of Sheep. It displays captured user names, passwords, domains and access methods – I actually had the two colleagues travelling with me show up here, even though I told them to not even open their laptops while at the con.

See you next year!