Dear readers
Sorry to say. This blog has currently lost some of its pictures, all of its links, all of its pages and menus. I am working on fixing it as fast as time and obligations allow me to.
Blog post have survived in their entirety.
Thanks for your patience
Shuntingyard
Postscript, same early morning
05:55 Pictures, pages and menus have been restored.
06:40 Links fixed, we are done (-;
Anagram of the day: “IT gem top disc”
I came across this doing a network configuration job during the week. While using bridge-utils can sometimes be troublesome, Debian offers a real cool and robust way to let you control devices in your Ethernet bridge via the distribution’s (inherited by Ubuntu) interfaces scripting.
In my example I was compelled to include a wireless – alas secured by old WEP – access point in the bridge:
# AP definition using madwifi iface ath0 inet manual wireless-essid MyEssID wireless-channel 1 wireless-key open s:secret_len_13
So far so trivial. But when this interface is down while the bridge comes up, the bridge itself will not have it included fully functioning. And services like DHCP – depending on the bridge – will not reliably be notified of events occurring on it. Now there lies Debian’s power: pre-up and post-down statements allow the bridge to control its physical ports and thereby learn about them in due time:
# My level 2 bridge iface br0 inet static address 10.64.0.1 network 10.64.0.0 netmask 255.255.255.128 bridge_ports eth0 ath0 pre-up /sbin/ifup ath0 post-down /sbin/ifdown ath0
While other distributions might be a bit troublesome on these subtleties, Debian and Ubuntu are just great (-;
Anagram of the day: “disc totem pig”
June 17, postscript
It is really simpler and safer to configure the access point mentioned above with a single pre-up iwconfig... line.
# My level 2 bridge iface br0 inet static pre-up iwconfig ath0 essid MyEssID channel 1 key open s:secret_len_13 address 10.64.0.1 ... bridge_ports eth0 ath0
And it is in conformance with the bridge-utils-interfaces man page – stupid me!
Reading your Twitter time-line can make you worry sometimes. Little more than a week ago I stumbled across a Tweet from a very trustworthy software engineer, stating passwords on any operating system could be cracked easily.
Introduction
Henceforth the shorthand MATHIS will be used for the blog post referenced by the above Tweet, as his author’s name is Blair Mathis.
As MATHIS dates from early 2009, we have to see if all details stated in it still hold true for today’s versions of the operating systems concerned.
I will verify all attacks mentioned in MATHIS, with the exception of OS X-related exposures. Although I give some attention to the more trivial attacks, the main focus of this article is on password cracking, using Philippe Oechslin’s rainbow tables (pdf). An alternative introduction to the subject – using less math – is available on Wikipedia.
While it is straightforward to verify the password cracking exposure concerning Windows, considerations for a similar attack against a state of the art Linux installation will not be validated by experiment here.
Trivial attacks
Beware of mounts! The distinction between data access in general and data access obtained with a cracked password is not too clearly made in MATHIS. Still today for NTFS (Windows) and Linux file systems, given physical access to the disk, a simple mount is sufficient to gain access to all data on partitions, be it by attaching the disk hardware to another machine, or by booting the machine under attack from USB storage or the like.
Therefore, file system access rights are not impregnable, independently of passwords known, and the cracking with rainbow tables depends on them not being impregnable anyway!
For an attack using GRUB (one of Linux’s boot-loaders), MATHIS states:
To change the password, turn on the computer and press the ESC key when GRUB appears. Scroll down and highlight ‘Recovery Mode’ and press the ‘B’ key; this will cause you to enter ‘Single User Mode’.
You’re now at the prompt, and logged in as ‘root’ by default. Type ‘passwd’ and then choose a new password. This will change the root password to whatever you enter.
This clearly holds not true for my Debian Squeeze workstation. Since MATHIS has been published, the configuration of GRUB appears to have been hardened beyond gaining access to recovery mode without knowing the root password.
Attacking Windows with Ophcrack
Ophcrack implements a rainbow table attack against windows and is freely available on SourceForge. I downloaded it, burnt it to disk, booted a Windows XP Professional workstation and got these results:
Interpretation:
I failed in beating MATHIS‘ 10 seconds for this attack. But results are still impressive. Now how does this compare to Linux?
State of the art Linux and rainbow tables
Let us take a random user entry from my Debian Squeeze test machine and look at its password hash:
tester:$6$uJft3Fyu$Li/scOEkr9cY6IxP/HiJ98TlRr4OkFqC1O6/w6mAqoPGxr6juUugTP3xXQ2jgJK8Y3IcCGkbb9ZSoUgwnEGPP.:14875:0:99999:
The $6$ part in it indicates the use of a SHA-512 hash. Here its cryptograpic salt is 8 bytes long ($uJft3Fyu$) and uses an alphabet comprising the set [a-zA-Z0-9./].
More clearly, we are talking about 64 distinct symbols to reuse on 8 bytes. Calculating the number of possible values for any salt to expect gives us 64 ^ 8 ≈ 2.81e14 – a very big number.
There is a specificity about rainbow tables and salted hashes: for every possible salt value a table has to be calculated, leading to infeasible storage requirements in our example.
But there is a way around this. Assume accessing the password hashes by mounting the attacked machine’s file systems (as discussed above). Since one salt occurs for every single hash and is not secret, we could just pick the root user’s salt, calculate rainbow tables for it and crack root’s password within reasonable amounts of space and time.
Conclusions
Anagram of the day: “Pit cited smog” – must be Brad Pit!
As a special treat every post in this blog has to end with an anagram, rearranging the letters in “midget topics” – until I run out.
Example: “diet GIMP cost” – few options for image processing…
What Ulm university published on Friday, May 13, makes most Android users a bit unhappy right now. Essential smart-phone resources like contacts and calendar data possibly compromised lead to shaky feelings. A few comments to soothe and stir these.
Can’t catch it any longer
As of May 18, rumors about a server side fix to the problem started coming through. A fix to be rolled out by Google within a week. If Google succeeds – and I bet they will – this is an achievement for two reasons:
Catcher’s topology
One thing is of essence for the attack: the attacker must have a packet sniffer in place. And the place is any IP subnet, your (unencrypted) packets travel through – from the place you sit, going all the way to Google’s servers.
In spite of terms used by the press, like “open/public WiFi networks”, there are more points in network topology where sniffing can be done. If “open” is mentioned, one best understands it in terms of higher likeliness.
You have but to consider your carefully configured WPA2-advanced encryption standard-network at home. You share its single key with your kids and their smart friends. Or you probably share it with guests like me, if you are receiving my kind (-;
Looking at industry strength network security specs and implementations, only some of those provide privacy in local networking for each station connected. Let’s hope no one’s employer is interested in those authentication tokens. Let’s hope there are no rouge Internet and tel-co providers.
And dear Google – catchy design?
So far I thought very highly of all your software engineers. From now on I only do of most. Why in the first place design and implement something that can be broken so easily?
Your flaw follows “Resign Patterns”
2. Destructural Patterns
2.4 DetonatorThe Detonator is extremely common, but often undetected. A common example is the calculations based on a 2 digit year field. This bomb is out there, and waiting to explode!
from the list published by Charalampos Arapidis.
Anagram of the day: “topic gets dim” – I hope it did not…
Time flies. I started this blog more than a year ago with an engineering colleague and friend. The essential idea back then was to write about middleware and middleware only.
Starting, we thought it all had to be very cleanly categorized and strict and formal. So it did lead to a tremendous amount of pondering and to diagrams like this one.
It never worked out as a blog however – there was just NO fun in writing for it.
So I decided to give it another try, this time without adhering to any strict rules. Consequently the blog’s name was to be changed. From the formerly intended and very serious Topics on Middleware it has been re-baptized to midget topics, allowing me to write about nice, tiny and unimportant things, just because I like to.
It should still mainly be a web log on ICT and computer science stuff. But of course there must be exceptions going off limits – or I won’t write for another year (;
Anagram of the day: “comet dip gist” – who knows?
