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

 

1.  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.
2. 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.

 

 

 

 

 

Today I upgraded, without any hesitation, my license for Curio that came with version 5 today.

I payed with Pay Pal and got a nice confirmation mail. Being a bit touchy about user interfaces and domain names (see my post earlier today) I post the following without comment.

 

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.