Weekly security week wrapup 23 and 24

It’s been two weeks since the weekly security wrapup, which makes ‘weekly’ a rather week term. Lots of excuses I could utter, but they’re all saying: “been busy”, which is another way of saying “I decided that other things were more important to do”. However, here we go again.

Cheap GPUs are breaking passwords faster

Obviously, they’re good at doing stupid things fast(er), and cracking passwords is about the stupidest task possible for a computer. However, for some of the strong stuff out there, like truecrypt, it does not really matter.  Truecrypt, for instance, has a rather slow initialization routine, which takes about 10ms on an average processor, which means you can check 100 passwords/sec. If a CUDA implementation were to increase that 1 million times (10^6), you can check 10^8 passwords per second. But if you have a 10 char password (upper/lower/digits), there are roughly 10^17 possibilities. Checking 10^8 passes/s means it takes 10^17/10^8/2 ~= 10^8 seconds. Which is another way of saying 76 years. That’s longer than the average time it takes for a disk to disintegrate by itself, last time I checked. Still, using CUDA to speed things up is quite cool.

http://www.zdnet.com/blog/hardware/cheap-gpus-are-rendering-strong-passwords-useless/13125

Mac Reversing: Starter’s guide

I’ve found this article on (OSX) malware analysis for beginners. It talks you through the beginning of using IDAPro and how to start analysing it. It’s excellent, but you need to keep paying attention, or you loose track quite easily.

http://jsz.github.com/reverse_engineering_mac_defender.html

Electric car trouble

And we’re not talking about the trouble you have driving your new electric Nissan Leaf and looking for a place to have lunch, dinner and a nap before your car is charged up. No, we’re talking about the car’s builtin firmware’s RSS reader telling all servers your current location, speed and whether you have the aircon on. That’s not funny.

http://www.theregister.co.uk/2011/06/13/nissan_leaf_privacy_invasion/

Weekly security week wrapup 22

Intercepting skype

Intercepting skype in transit is quite complicated. The ‘oracle’ needed to decode the signalling traffic is quite well known and understood, resulting into legible signalling information. The primitives used in the user-to-user voice traffic are also well known, but this knowledge does not gain you any understanding of the contained traffic. Knowing you’re looking at AES and RSA doesn’t make it any more fun to start cracking.

This week we also heard some news that a Russian reverse engineer, Efim Bushmanov, has been able to reverse engineer skype to the point where it should become possible to write your own (open source perhaps) skype client. Skype (being aquired by Microsoft, conspiracy theorists unite, but that’s a different topic) does not like this one bit and brought in the big lawyers to tell Efim that he was violating the EULA.

But there are other ways to gain access to the traffic: intercept at the end-point, where the traffic has been decrypted for you. This article in the wall street journal describes quite detailed how the Egyptian government has been using this method to intercept traffic of young dissidents.

Lockheed Martin breach

All over the news: Lockheed Martin has been breached because it used the RSA tokens that had been compromised a couple of weeks before that. LM has the resources to actually detect a compromise like that, but there are way more small companies that use RSA tokens. How are they going to handle it? This is not the last breach we’ve seen that’s caused by the broken RSA tokens.

Lowcost USB Bluetooth sniffer

This is so nice, and it’s NFH (Nice for Hometinkering)-appeal is big. A small usb bluetooth sniffer, ehm, bluetooth monitor. Ordinary bluetooth devices are very difficult to get in a monitoring mode and other commercial bluetooth monitoring tools cost you an arm and a leg and your soul. This one is selling for under 100 GBP, and you can make it more cheaply if you can solder, which I cannot.

Pentester’s cheat sheet

If you’ve been doing pentesting, one of the goals is to get a shell on the machine. This article lists a number of methods to (ab)use common tools to get the shell working. It’s a nice cheat sheet.

Wrapup for week 21

I’ve started to do something different. I’ll try and create a wrapup of the stuff on the security and/or forensics arena that got my attention. Some may be quite interesting, others may be more fleeting.

Chrome false start

Google has added a feature to Chrome which enables it to perform a SSL-handshake in less messages, resulting in a quicker session setup for the end-user. The beautiful thing is, that the only thing that needs adjustment is the browser, not the server. That’s very nice, and here is a writeup by @cyberwar on the implication that this effort will have on the adoption of SSL.

IPv6 failure coverup in chrome

If you have a network setup where IPv6 is somewhat broken, you are in trouble. The definition in this case for ‘somewhat broken’ reads as: you have a IPv6 address, but no real IPv6 connection to the interwebs. What happens is that you ask for an address to the DNS, which hands you a AAAA and an A record back. You try the AAAA record, which will fail, but it may take some time for the browser to actually notice that the IPv6 connection will not do what it intended to do, after that it will try the A record for IPv4. Chrome now has a feature called IPv4-fallback, which works like this: chrome tries to use the AAAA record, but sets a really low timer (300ms) on that connection. If it doesn’t get an answer within that time back from the server, it will start an IPv4 connection as well for the A record. The first connection to complete, either the AAAA or A, will be chosen to transfer the request and/or data. On a fast connection, this is a quite elegant way for the browser to solve the end-user’s broken network. Naturally, the end-user should fix his network, but with broken CPE it might not be that easy to do. Networkworld has an article on this, as well as the upcoming IPv6 world day (8 June 2011).

Google prediction API

The Google Prediction API may be the prelude of an upcoming trend, where the algorithms and computing power from Google can be used for your own benefit. The example described in the article is done by Ford motor company, but when you start to think about it, there may be a lot more cases where it makes sense to use the Google machine learning algorithms to make the business more profitable by helping the end-user attain his goals more easily.

Roll your own Supercomputer for $1060/h

To finish this weekly wrap-up: how to roll your own supercomputer for $1060/h, which is quite cheap once you think about it. I cannot run computing power like this for this tariff (when also including downtime and idletime).

Building Boost-Graph-Library with Python

Today I finally found why bgl-python wasn’t building, there was a three-line buglet in boost/graph/astar_search.hpp found by Andy Tompkins. By applying his patch to astar_search.hpp (and including it in the bgl-python codebase, it builds without errors (only some strict-aliasing rule warnings remain).

Best is: it also compiles on Mac OS X 10.6.3 with XCode 3.2.1

But, so far I must say I really hate bjam as a building tool. I’m seriously considering going with cmake as build system. Any opinions whether or not that’s a good idea?

OpenWRT 8.09.2 and ipv6

After spending quite some time with the firewall rules inside the openwrt kamikaze 8.09.2 installed on my Linksys WRT54GL, I thought that posting the end result might be handy for others.

• step 1, install the following packages: ip6tables, kmod-ipv6, radvd, 6scripts.
• step 2, change the following line in /etc/init.d/6tunnel
ip tunnel add $tnlifname mode sit remote $remoteip4 local $localip4 ttl $ttl
  into
ip tunnel add $tnlifname mode sit remote any local $localip4 ttl $ttl
  because if you don’t the outgoing packets are to remoteip4 (192.88.99.1), but the incoming packets are from 192.88.99.2. That’s not handled properly somewhere inside the kernel/firewall/ip6tunnel config. You can see this is happening by the “ICMP protocol 41 unreachable” messages back to 192.88.99.2.

So, what goes into /etc/config/6tunnel:

config 6tunnel
option tnlifname ‘6tunnel’
option remoteip4        '192.88.99.1'
option localip4                <insert your ipv4 address>
# convert your external ipv4 address into 8 4-nibble hex digits
#
option prefix                ‘2002:<hex variant of ipv4>:1::1/64’
option localip6                “2002:<hex variant of ipv4>::1/16”
option ttl                64


And the last step is adding a rule admitting ipv6 packets in (/etc/config/firewall)

config rule
option '_name'                ‘6tunnel’
option src                wan
option proto                41                # ipv6
option target                ACCEPT


And just to have everything documented, this is a sample firewall script for protection of your ipv6 stuff:

#!/bin/sh
# Copyright (C) 2006 OpenWrt.org
PUBIF=‘6tunnel’
ip6tables        -F
ip6tables        -X
ip6tables        -t mangle -F
ip6tables        -t mangle -X
# Allow everything on loopback.
ip6tables        -A INPUT -i lo -j ACCEPT
ip6tables        -A OUTPUT -o lo -j ACCEPT
ip6tables        -P INPUT DROP
ip6tables        -P OUTPUT DROP
ip6tables        -P FORWARD ACCEPT
# Accept only stuff incoming if there's a SYN in there.
# We really want ESTABLISHED, RELATED, but unfortunately that's not supported (yet) in ip6tables
ip6tables        -A INPUT -i $PUBIF -p tcp ! --syn -j ACCEPT
ip6tables        -A INPUT -i $PUBIF -p ipv6-icmp -j ACCEPT
ip6tables        -A OUTPUT -o $PUBIF -p ipv6-icmp -j ACCEPT
ip6tables         -A INPUT -i $PUBIF -p tcp --dport 80 -j ACCEPT # accept HTTP
ip6tables         -A INPUT -i $PUBIF -p tcp --dport 22 -j ACCEPT # accept SSH
ip6tables         -A INPUT -i $PUBIF -p tcp --dport 25 -j ACCEPT # accept SMTP
ip6tables        -A INPUT -i br-lan -j ACCEPT
ip6tables        -A OUTPUT -o br-lan -j ACCEPT
ip6tables        -A INPUT -i $PUBIF -j LOG
ip6tables        -A INPUT -i $PUBIF -j DROP


Capturing without being root

It is sometimes necessary to capture the content of network traffic. Most people use a tool like wireshark or tcpdump to do that. Since these tools have the need to listen in promiscuous mode to the network interface, most people run them as root. Wireshark has had a lot of vulnerabilities in the code, which is unavoidable with the enormous amount of protocols being supported by reverse engineering. They have taken steps in the past to mitigate the impact of vulnerabilities by using a separate tool, dumpcap, which has a much smaller and simpler codebase.

Still, most people run wireshark as root, ‘because then it works’. Right, Gerald Combs has written an article on how to configure your system with capabilities so you don’t have to run wireshark as root any more. It works by granting users you want to be able to capture, the capability of being able to capture. That simple.

Building Boost/Python/Graph library

There’s a nice library called bgl-python which can be used to handle graph related problems in python using the, in my opinion, good quality code of the boost graph library. However, bgl-python does not seem to be maintained anymore, which is quite a pity.

Following one of the comments on this blog, I tried to get bgl-python to compile and I got everything compiling with boost-1.42.0, except for one file, astar_search.cpp, which fails with an error message of roughly 50k. Yes. One error: 50k of tekst, it’s got to be C++. The offending line, property_map.hpp:325 looks fine to me:


static_cast(pa)[k] = v;


The problem appears to be in the [k], which, for some case, is a void* instead of unsigned int. I can understand that’s a problem, but I’m currently at a loss why this is happening.

To be continued…

Update:

Nothing so far has worked, astar_search keeps getting the compile error. Any ideas are welcome!

Randy Pausch

I’ve recently come across the last lecture by Randy Pausch. It’s very inspirational and it works to look at stuff from his perspective. Last week I ran into a brick wall trying to accomplish something which I really wanted.

At first I was really disappointed about things not working out the way I wanted, but one day later I remembered the following:

Brick walls are there for a reason. The brick walls are not there to keep us out. The brick walls are there to show how badly we want something. Because the brick walls are there to stop the people who don’t want something badly enough. They are there to keep out the other people.
– Randy Pausch ( 1960-2008 )

When I was considering this, I also remembered a remark by Zedd from the Sword of Truth Series: Don’t think about the problem, think about the solution.

So far these small pieces of advice, although one is from a fictional character, if anything, it helped lift my spirit to a considerable higher level. Actually thinking about the solution is a lot more creative than wallowing in despair.

Building boost on Mac OS X 10.6

Today I finally had the time to verify that the problems building boost on Mac OS X 10.6 aka Snow Leopard using the compiler enclosed in XCode-3.2 were over. And indeed, building boost 1.42.0 is a nobrainer: just unpack and build.

I’ve built it with these options:

bjam --build-dir=../boost_build --layout=versioned toolset=darwin architecture=combined address-model=32_64 link=shared,static stage


Building boost on Mac OS X 10.6 with XCode 3.2

Getting boost to build in ‘fat binaries’ is a pain when you’ve just switched to XCode 3.2. Switching to XCode 3.2 is somewhat obligatory, because that also brings you the SDK for Mac OS X 10.6, aka Snow Leopard. And when you run the Snow Leopard, you want the SDK for it as well. It sounds so simple.

The Apple version of gcc, included in XCode, stops building boost in fat versions, it works for targeted versions (i.e. with only one architecture). But, if you want to build ‘universal’ binaries that work in 64bit and 32bit mode, you’re out of luck.

I got it to build this morning, thanks to some discussions on the boost mailing list. And it == boost 1_40_0, with XCode 3.2 on Snow Leopard.

This is the command-line I used:

bjam --build-dir=../boost_build --layout=versioned toolset=darwin architecture=combined address-model=32_64 link=shared,static install

And here is the patch I created to get it to work. It boils down to: remove all the ppc entries from the tools/build/v2/tools/darwin.jam, because the XCode compiler does not offer support for PPC anymore. And, you have to remove the “-m64” option in the gcc.jam, because the xcode compiler does not like to have -arch x86_64 -arch i386 -m64 all together on the command-line.

But, if you take the road of building your code on XCode 3.2, you specifically eliminate all those users still using a PPC based Mac. That might not be what you intended. In that case you probably need to add the -V 4.0.1. option to gcc/g++ in which case you use the older compiler (from XCode 3.1), which might or might not be what you need for your project.

(Sorry for the stupid looks on the patch, but wordpress mangles stuff with the <code> tag).


diff --recursive -u boost_1_40_0.orig/tools/build/v2/tools/darwin.jam boost_1_40_0/tools/build/v2/tools/darwin.jam
--- boost_1_40_0.orig/tools/build/v2/tools/darwin.jam 2009-04-14 09:59:30.000000000 +0200
+++ boost_1_40_0/tools/build/v2/tools/darwin.jam 2009-09-06 08:01:26.000000000 +0200
@@ -304,9 +304,9 @@
: $(values) ;
}

-arch-addr-flags darwin OPTIONS : combined : 32 : -arch i386 -arch ppc : default ;
-arch-addr-flags darwin OPTIONS : combined : 64 : -arch x86_64 -arch ppc64 ;
-arch-addr-flags darwin OPTIONS : combined : 32_64 : -arch i386 -arch ppc -arch x86_64 -arch ppc64 ;
+arch-addr-flags darwin OPTIONS : combined : 32 : -arch i386 : default ;
+arch-addr-flags darwin OPTIONS : combined : 64 : -arch x86_64 ;
+arch-addr-flags darwin OPTIONS : combined : 32_64 : -arch i386 -arch x86_64 ;

arch-addr-flags darwin OPTIONS : x86 : 32 : -arch i386 : default ;
arch-addr-flags darwin OPTIONS : x86 : 64 : -arch x86_64 ;
diff --recursive -u boost_1_40_0.orig/tools/build/v2/tools/gcc.jam boost_1_40_0/tools/build/v2/tools/gcc.jam
--- boost_1_40_0.orig/tools/build/v2/tools/gcc.jam 2009-07-11 13:04:31.000000000 +0200
+++ boost_1_40_0/tools/build/v2/tools/gcc.jam 2009-09-06 08:11:17.000000000 +0200
@@ -375,7 +375,8 @@
}
else
{
- option = -m64 ;
+ # option = -m64 ;
+ option = ;
}
}
OPTIONS on $(targets) += $(option) ;