Trend-Watcher

Credit Card , Domain Name, Spoofing and Phishing

Sun, 24 Aug 2008 00:01:53 +0200

Updated: Aug 22 to add that the Postbank now informs their users about the use of the arcot domain.
Updated: Aug 24, some slights textual edits.

Often people argue that DNS spoofing will not impact peoples ability to do banking and such. With the current practices both with user interfaces as well as the practices that the banks themselves deploy I claim that this is close to nonsense.

The basic attack is that user Alice wants to connect to her website: www.postbank.nl, in order to do a secure transaction the bank will redirect her to a secure website. If Alice is smart she will check the security of the connection by looking at the padlock and verifying if the domain she connects to make sense.

This is not going to work as long as:

browsers do not display the domain and only a padlock, so users need to actually dig deep before they are aware of possible problems
and banks happily redirect to domains hosted by unknown 3rd parties so that users are used to providing information to seemingly unrelated parties.

The obvious DNS based attack is to redirect the unsecured postbank.nl site and provide link to postbank.malice.nl that have valid certificates. We all know that getting a certificate for postbank.malice.nl is a trivial matter, it takes an e-mail address and a credit card number.

Below is an example that banks take it for granted that users trust Arcot.com as a middle man for either Mastercard or the Postbank. And personally I have never heard of arcot.com, so what do I know.

The point I am making is that as long as Banks and Creditcard companies are implementing practices that make users get used to being redirected to completely unrelated, albeit HTTPS secured domains, they will not help to create a mindset where users will understand when they are subject to certain kinds of fraud, like phishing.

My experience today

Apparently there is some new mechanism introduced to secure Internet credit card payments. Its called MasterCard SecureCode. I did not know about this, but that may be because I have not seen the snail mail yet. I was introduced to this new protection mechanism to protect against fraud while trying to pay for a conference.

The original website redirected me to a site from tripledeal.com for the payment transaction. Even though the original website did not tell me that the transaction was to be handled by triple deal I decided to take the leap of confidence based on prior experience.

So far so good.

At the end of the payment process a new validation step is introduced: I am invited to go to my bank to validate the payment.

So pressing the "To Your Bank" button opens up a new window.

Oh... wait.

This screen asks me about details about my credit card. I need to be extra suspicious about entering information. Let me click on the padlock to verify that I am actually talking to my bank.

Oh.. so an organization called arcot.com is claiming to represent my bank? I do not believe that, anybody could be claiming to be my bank, even with that little padlock in place.

So, there is this new validation scheme I have never heard of, that needs some of my credentials, and that takes me to a site that does not seem to be my bank? What more do I need to suspect that I am subject of an elaborate phishing attack?

Let me read the page once more... Oh it says more information can be found at postbank.nl/SecureCode. So lets go there https://postbank.nl/SecureCode .... timeout. Let me try over a non secure channel and see what I get (depending on trailing/nontrailing slash).

So lets call the bank.

I called the Postbank's creditcard helpdesk I got a perfect explanation about the introduction of the SecureCode technology. I explained that I got a pop-up from postbank.arcot.nl, was put on hold, and was then explained that dealing with Arcot was OK.

The fortunate point was that I did not need to explain that me dealing with arcot.com was in sharp contrast with the anti-phishing policies that the banks deploy, and that the postbank helpdesk person actually understood that the pop-up should have originated from a postbank.nl or maybe mastercard.com domain. But he had no way to escalate the problem and asked me to report in e-mail.

Time to write a mail. I plan to post the correspondence in a follow up.

Update Aug 22.

It seems something happened. The postbank website now mentions:

* Let op, als u hierop klikt wordt u naar een website geleid die geen Postbank adres heeft. Controleer of het adres begint methttps://postbank.arcot.com. Hiermee heeft u een veilige verbinding om uw SecureCode te registreren.

Which is basically a warning that you will be dealing with arcot.com and that that is OK.

This does partly address the problem

Technically this information is posted on a non secure website, a DNS cache poisson could lead to a spoofed site. It would be better if this information would also be accessible via HTTPS which it is not.
The problem is still that the bank creates an expectation pattern that it is OK to deal with a domain name that is not rooted in the postbank domain. And that is exactly the thing they should try to avoid.

Who knows there will be a structural solution for this problem.

Export Article

Thu, 14 Aug 2008 15:35:25 +0200

WIRED seems to think I am an export article:

Olaf Kolkman, a Dutch networking export, says there's no time to waste. The only way for DNSSEC to work is for the top-level zone file -- which lists the specifics for top-level domains like .gov -- to be signed by a trusted authority.

Do it yourself: VPN tunnel from Mac OSX to FreeBSD

Tue, 12 Aug 2008 12:27:00 +0200

Because I need to do a demonstration for which I need public IP addresses and I am not sure wether I will be behind a NAT box I decided to configure my Mac box to establish a VPN to my FreeBSD server.

The prerequisite is that you actually have public IP addresses to create a tunnel to. I've been using a /28 so my colleagues can make use of the tunnel too.

Setting up PPTPs is a bit involved since it involves understanding the various layers that are involved.

Below is an annotated configuration file /usr/local/etc/mpd5/mpd.conf.

In the example below assume that 10.15.22/24 is a piece of public address space. That 10.15.22.177-182 are the addresses assigned to users.

#################################################################
#
# MPD configuration file for a VPN
#
#
#################################################################

startup:
# set user username password [admin|operator|user]
# This command configures which users are allowed to connect
# to the console. It may be invoked multiple times with
# different usernames.
set user admin secret admin
# set user foo1 bar1
# configure the console
set console self 127.0.0.1 5005
set console open
# configure the web server
set web self 127.0.0.1 5006
set web open

# We define a new interface for eache possible user
default:
load pptp_server

# Anotated Setup for pptp_server
pptp_server:
# Pool of addresses to be used:
set ippool add LANPOOL 10.15.22.177 10.15.22.182

# Create a bundle template named VPN
create bundle template VPN

# Iterface configuration
# On demand is only useful when we want to make an outgoing
# connection
set iface disable on-demand
set iface idle 0

# Since we do not want to play routing tricks we'll proxy arp
# to the LAN so traffic will find its way to the interace
set iface enable proxy-arp
set iface enable tcpmssfix

# IP options
# TCP header compression
set ipcp yes vjcomp

# Set the IP range
# pick a fixed local address and allow assignment from a shared pool
# To assign a fixed address to a user use something like:
# joe "foobar" 10.15.22.178
# bob "foobar" 10.15.22.179
0 # in the mpd.secrets file
# that would always provide joe with the 178 and bob with the 179 address
set ipcp ranges 10.15.22.48/32 ippool LANPOOL
# This is the resolver that is available on the local lan
set ipcp dns 10.15.22.155

# Set the encryption on the VPN, Mac OSX uses PPTP uses this too.
set bundle enable compression
# Let this bundle use mppc
set ccp yes mppc
# Continue to configure mppc
# Use 128 bit MMPE encryption
set mppc no e40
set mppc yes e128
# Less secure but fastre recovery from lost packets
set mppc yes stateless
# Require Encryption

#Create links

create link template VPNLINK pptp
# Set bundle template to use
set link action bundle VPN
# Multilink adds some overhead, but gives full 1500 MTU.
set link enable multilink
# Enable address and control field compression, and protocol
# field compression
set link yes acfcomp protocomp
# Turn pap and chap type authentication off.
set link no pap chap

# Require CHAP authentication from the peer NB: Use enable The
# use of enable and accept have slightly different meaning in
# the context of PAP and CHAP.
set link enable chap

set link keep-alive 30 300
# We reducing link mtu to avoid GRE packet fragmentation.
set link mtu 1460
# Configure PPTP # This is the address to which you will have to connect using your vpn client
set pptp self 10.15.22.48
# Allow to accept calls
set link enable incoming

Troubleshooting

Having all configured out of the box things did not work as expected, after establishing a connection (by which the client was assigned 10.15.22.178) I could not forward traffic to the Internet. My suspicion was that proxy arp was not working on the FreeBSD server.

To troubleshoot proxy-arp you login to a machine that lives on your LAN, different from your client. And ping the address that the client has been assigned.

Then you validate by first pinging and then checking if the arp address points to the interface by which your server is connected to the LAN.

otherbox# ping 10.15.22.178
otherbox# arp 10.15.22.178
? (10.15.22.178) at 0:10:4b:bc:24:1b on en0 [ethernet]
freebsdbox#ifconfig xl0: flags=8843 metric 0 mtu 1500
options=9
ether 00:10:4b:bc:24:1b
...

Those MAC addresses look good.. So proxy-arp was not the problem. What could be another reason why packets from the pptp interface do not make it to the xl0 interface and onto the net? But off course IP forwarding. If you forgot a sysctl net.inet.ip.forwarding=1 on your PPTP server then packets will never make it. So make sure your /etc/sysctl.conf contains such line.

Setting up your connection to this VPN server is trivial, just follow the instructions in your apple help instructions.

Choose Apple > System Preferences, and then click Network.

Click Add (+) at the bottom of the network connection services list, and then choose VPN from the Interface pop-up menu.
Choose what kind of VPN connection you want to set up from the VPN Type pop-up menu, depending on the network you are connecting to, and give the VPN service a name.
Enter the server address and the account name for the VPN connection.
Click Authentication Settings, and enter the user authentication information you were given by the network administrator.
After entering the user authentication information, click OK, and then click Connect.

If you want all your traffic routed via the VPN make sure you check the the "Send all traffic over VPN connection".

The effect of policy....

Sat, 17 May 2008 16:08:55 +0200

OpenFire, IPv6, and FreeBSD

Tue, 29 Apr 2008 10:12:46 +0200

With IPv6 deployment I'd like to put my money where my mouth is so after the IETF IPv6 only network experiment I wanted to make sure that my jabber server runs both IPv6 and IPv4. I ran into a bunch of problems:

OpenFire is documented to run IPv6. It draws its capabilities from the java implementation it runs on.

The default Java virtual machine that comes with the FreeBSD ports is diablo-jdk15. That port does not come with IPv6 enabled. You can test that by using the ListNets program that is available from the Java Tutorial site. Copy and paste the code on that page into a file called ListNets.java and test

$ javac ListNets.java
$ java -version
java version "1.5.0"
Java(TM) 2 Runtime Environment, Standard Edition (build diablo-1.5.0-b01)
Java HotSpot(TM) Client VM (build diablo-1.5.0_07-b01, mixed mode)
$ java ListNets
Display name: lo0
Name: lo0
InetAddress: /127.0.0.1
Display name: rl0
Name: rl0
InetAddress: /213.154.224.4
InetAddress: /213.154.224.1
$

I double checked if there is a compile time configuration option to turn on IPv6 for diablo, there is none. Off to install the jdk1.5 port. Here you have to start with a "make config" in order to enable IPv6 support and compilation will take an hour or so. Once installed the test program will show all interfaces:

$ /usr/local/jdk1.5.0/bin/java -version
java version "1.5.0_14-p8"
Java(TM) 2 Runtime Environment, Standard Edition (build )
Java HotSpot(TM) Client VM (build 1.5.0_14-p8-olaf_28_apr_2008_16_18, mixed mode)
$ /usr/local/jdk1.5.0/bin/java ListNets
Display name: lo0
Name: lo0
InetAddress: /fe80:5:0:0:0:0:0:1
InetAddress: /0:0:0:0:0:0:0:1
InetAddress: /127.0.0.1

Display name: rl0
Name: rl0
InetAddress: /2001:7b8:206:1:0:0:4:53
InetAddress: /2001:7b8:206:1:0:0:0:53
InetAddress: /2001:7b8:206:1:0:0:0:1
InetAddress: /fe80:2:0:0:240:f4ff:fe37:8232
InetAddress: /213.154.224.4
InetAddress: /213.154.224.1

Starting openfire manually, after setting JAVA_HOME to /usr/local/jdk1.5.0/ one can validate that the program actually binds to the tcp6 sockets:

openfire java 96677 11 stream (not connected) openfire java 96677 13 tcp6 *:7777 *:*
openfire java 96677 16 tcp6 *:5269 *:*
openfire java 96677 17 tcp6 *:5229 *:*
openfire java 96677 22 tcp6 *:9090 *:*
openfire java 96677 25 tcp6 *:9091 *:*
openfire java 96677 30 tcp6 *:5222 *:*
openfire java 96677 33 tcp6 *:5223 *:*

Testing the IPv6 connection towards the openfire management interface using "telnet ::1 9090" demonstrates that the IPv6 connection works. However a "telnet 127.0.0.1 9090" fails. So we only have IPv6 and no IPv4 connectivity.

So, why is this?

FreeBSD (and open and net BSD) turn off IPv4 binding to IPv6 sockets by default. This behavior is controlled using the "net.inet6.ip6.v6only" kernel option. One workaround to solve this problem is to set net.inet6.ip6.v6only=0. However this could lead to cause possible security problems. The security problems in Itojun's draft are the only security issues I am aware off and they can be mitigated by filtering on ::ffff:0:0/96 network traffic e.g. at ones network perimeter. That traffic should not be on the network in the first place (see e.g. informationa RFC number RFC5156 section 2.2).

With net.inet6.ip6.v6only=1 it is impossible to use AF_INET6 to bind to both IPv6 and IPv4 addresses.

As an alternative I have tried to bind to interfaces explicitly in the openfire.xml configuration but that fails too as it seems that openfire only accepts one instance of the network.interface configuration option. I would argue that on multihomed machines one may want to bind to a subset of the available addresses instead of binding to the wildcard and that allowing for address family agnostic specification of one or more interfaces is the best solution.

Starting two instances of openfire, one on IPv6 and one on IPv4, by specifically binding to the v6 and v4 interfaces is no solution either because the IPv4 server would not know of the presence of clients registered on the IPv6 server.

In order to get a working dual stack openfire running on FreeBSD do the following.

The HOWTO

add the following lines to your /etc/rc.conf:
# Allow IPv4-mapped addresses ipv6_ipv4mapping="YES"
Make sure your java distribution supports IPv6.
- /usr/ports/java/diablo-jdk15 does not support IPv6
- /usr/ports/java/jdk15 and /usr/ports/java/jdk16 do support IPv6, but you have to rune make config and specifically set IPV6 support before building!
Edit your /usr/local/etc/rc.d/openfire to allow for a different java vm to be used:
--- /usr/local/etc/rc.d/openfire.bak 2008-05-02 10:22:16.000000000 +0200
+++ /usr/local/etc/rc.d/openfire 2008-05-02 10:23:00.000000000 +0200
@@ -20,6 +20,9 @@
# Set it to java home directory.
# openfire_javargs (args): Set to -Xmx256M by default.
# See java -h for available arguments.
+# openfire_java_home (path): Set to /usr/local by default.
+# Sets JAVA_HOME before calling java
+# See javavm(1)

. /etc/rc.subr

@@ -34,6 +37,9 @@
: ${openfire_libdir:=/usr/local/share/java/classes}
: ${openfire_home:=/usr/local/share/java/openfire}
: ${openfire_javargs:='-Xmx256M'}
+: ${openfire_java_home:=/usr/local}
+
+export JAVA_HOME=${openfire_java_home}

pidfile=/var/run/${name}.pid

Hopefully the openfire ports maintainer will apply this patch, or offer a similar solution in a forthcoming release.
Set openfire_java_home in your /etc/rc.conf:
# Start openfire, make sure to use an IPv6 enabled java engine
openfire_enable="YES"
openfire_java_home="/usr/local/jdk1.6.0/" # or your local variety
Verify that both IPv4 and IPv6 are being used. Allow openfire a few seconds to bind to the various interfaces en then use sockstat to verify if tcp4 and tcp6 are in use:
# sockstat | grep openfire
openfire java 12742 27 stream (not connected)
openfire java 12742 29 udp46 *:10020 *:*
openfire java 12742 30 tcp46 *:7777 *:*
openfire java 12742 31 tcp6 ::1:60235 ::1:60234
openfire java 12742 33 tcp46 *:5229 *:*
openfire java 12742 35 tcp46 *:5269 *:*
openfire java 12742 45 tcp46 *:9990 *:*
openfire java 12742 49 tcp46 *:9991 *:*
Don't forget to block ::ffff:0:0/96 traffic on your network

Some Tweaks

In the DNS I pointed the SRV records to a host with both an IPv4 and IPv6 address, something like:

_xmpp-client._tcp.jabber.secret-wg.org. 300 IN SRV 0 0 5222 jabber.secret-wg.org
jabber.secret-wg.org. 3600 IN A 213.154.224.48
3600 AAAA 2001:7b8:206:1:0:1234:be21:e31e

It turns out that with the clients I tried (iChat and Adium) I was not able to connect to the server while being connected to an IPv6 only network. When specifically connecting to the server by entering jabber-6.secret-wg.org (with AAAA RRs and without A RRs) things work like a charm.

Note also that you have to generate a certificate with a number of alt names: jabber.secret-wg.org *.jabber.secret-wg.org, jabber-6.secret-wg.org, and *.jabber-6.secret-wg.org. Create an openssl configuration file with information similar to the following, create a certificate request and get it signed with for instance cacert.

commonName = Common Name (eg, YOUR name)
commonName_default = jabber.secret-wg.org
0.subjectAltName = Subject altname
0.subjectAltName_default = DNS:*.jabber.secret-wg.org
1.subjectAltName = Subject altname
1.subjectAltName_default = DNS:jabber-6.secret-wg.org
2.subjectAltName = Subject altname
2.subjectAltName_default = DNS:*.jabber-6.secret-wg.org

[Edited to clarify a few points on April 30]

[Edited to add the Howto section on May 2]

[Edited to add the Some Tweaks section on May 7]

Design your own life

Tue, 19 Feb 2008 18:16:01 +0100

The other day I received a brochure from IKEA, the last page featured an advertisement by "DELA" a dutch funeral insurance company. Even though the disclaimer at the bottom of the add that the advertisement was not an initiative by IKEA it made me think about the essential missing products in the IKEA "design your own life" philosophy.


Design your own life
	Aska
	Swedish Urn colors

	€ 149.00
	Kista
	Swedish Pine Coffin

	€ 349.00

Off course this is all parody and the marvelous IKEA company is not associated with any of the above.

BubbleBable

Sun, 10 Feb 2008 22:05:06 +0100

Seems like I was mentioned... I hope in a favorable context.

Q12　最近メインで使っている言語は？　なぜその言語に引かれたのですか？

Perl。それまではawkやCを使っていて、今でもたくさん使っているけれど、PerlはCでやりたいことをプロトタイピングするのに実は便利。システムコールとかよく似た名前で扱えるしね。後、よいライブラリがそろっている。DNS関連では、オラフ・コルクマン（Olaf Kolkman）のNet::DNSなんか結構素敵。

　Cは知っておくと困らない。おかげで今もなんとかメシが食えてます。別に簡単な統計計算をCでやったっていい。32ビット同士のかけ算で、結果が64ビットであってほしい、というのをアセンブリ言語以外で書くのって結構面倒だからね。

　オブジェクト指向的なものにはイマイチ慣れなくて、使わずにいるんだけど、データや実行しているコードの流れさえつかめば、どういう言語でも対応はできると思う。Concurrency（同時に複数のコードが走っていること）を考えると、順番が書かれている通りに実行されるわけじゃないから、難しいけど。

　言語オタクにはなれなかったというか、劣等感があります。Prologとか、全然分かっていない。LISPのS式は、素晴らしいと思うし、教養の1つとして知っておくべきだと思うけど。JavaとCommon Lispが近縁なんだよな、そういえば。

　ツールというか、ゴチャマンとした処理系としては、Rは面白いと思ってます。プログラミング言語というよりは、統計処理関連アプリだけど :-）

Confit de Canard

Fri, 28 Dec 2007 23:01:53 +0100

This years Christmas I decided to live up to the Duck Dogma ("Whenever you see Duck, eat it!") and made Confit de Canard.

Confit is a means of preparation where one starts with salting the meat and then cook it gently, drowned in fat.

Duck has the property to turn dry when prepared, you can prevent that by making sure the meat does not boil.

When roasting the meat that can be prevented by roasting it on a high temperature so that it is sealed by its own crust, and then leaving it on a relatively low fire until its done.

The alternative way of preparing is to seal the meat in fat and slowly let it simmer. I have been told that can prepare beef at about 40 degrees Centigrade as long as you keep it at that temperature for a few hours, never tried it though.

I prepared the confit for 9 persons, so I bought myself 18 legs and 5 cans of goose fat.

I rubbed the legs with salt, crushed pepper and pimento. This is something that I intend to improve on the next time I prepare this. Then I plan to salting the legs by marinade them in a salt solution for a day or so.

Arrange the legs in a casserole and cover with goose fat. Use sufficient fat to make sure the legs are covered when the fat is melted. It took me exactly 5 pots of 0.5 liter.

For taste add a few cloves of garlic, a few onions and a few leaves of laurel.

Put this in your oven, temperature around 100 degrees centigrade so that the meat itself is at about 90 degrees. Leave this simmer for about 3 to 4 hours. That is all, real easy, cannot fail.

By the way, a pot of goose fat of 0.5 liter costs about 4 Euro, I've never spend so much money on grease. But fortunately its great fat to prepare potatoes in.

Planet Earth to M$.... beeebbb... noiisssseee... beeepppp

Thu, 15 Nov 2007 09:52:02 +0100

I just read an article on ZDnet. It describes a demo of an exploit on an un-patched XP SP1 machine on an open wireless network. The MS executive was surprised by the ease of the attack.

Nick McGrath, head of platform strategy for Microsoft U.K., was surprised by the incident.
"In the demonstration we saw, it was both enlightening and frightening to witness the seeming ease of the attack on the (Windows) computer," said McGrath. "But the computer was new, not updated, and not patched."

The first sentence makes one wonder on which planet has this man been hiding. The second sentence makes me wonder how machines are sold other than new, not updated, and not patched.