Loading...

Browsing category archives: Technical

More Postbank Secure Code annoyances

Remember my previous post on this topic. I went back to the postbank site to see if things had improved. Turns out they have not. Here is a screenshot from the page explaining the SecureCode. Its all about the footnote (the last line on this screenshot).


The last line reads:

Caution: When you click on this link you will be lead to a website that has no Postbank address. Check wether the address starts with https://postbank.arcot.com. With that you will have a safe connection to register your Secure code

I will not be repeating my argument that notifying, from a non-http- secured page, to a https page breaks users expectation (why would you trust postbank.arcot.com over of postbank.secure-bank-services.com). Instead, I want to highlight that if you click on the link that displays “https://postbank.arcot.com/” you actually get redirected via a non secured link like  http://www.postbank.nl/ing/pp/page/external_link/redirect/0,3042,1859_180483_849292156,00.html?ExternalLinkId=849292156

Again, that is unnecessarily  complex and confusing for users.

Controleer of het adres begint met https://postbank.arcot.com Hiermee heeft u een veilige verbinding om uw SecureCode te registreren.

Edit April 8, 2012: Clean-Up HTML code.
Remark April 8, 2012: While this is not common practice with any Dutch bank I know of I have seen this type of practice elsewhere.

From the Waste of Time Dept.: applescript IMAP nested folder creations

This is for those folk in google land querying for “applescript make new mailbox Imap”

Today I finished my first applescript. Using components from several other scripts I set out on the following task.

  • For all messages in a set of selected Imap folder
    • Find messages that originate from a mailinglist
    • Apply heuristics to determine the domain of the mailinglist and the name of the mailinglist
    • File the message in an IMAP folder with name “ArchiveRepository/domain.of.list/listname/<year>/<Quarter>

One of the subtasks is to build the mailboxes in IMAP with these directory structures. Taking an existing example (The MailArchiveByDate scropt from Dough Hellman) I first took a left to right approach. Writing out what happens internally in a test script would look like:

— Emulating what would happen in the code loop:
make at the end of the mailboxes of account (name of theAccount) new mailbox with properties {name:(“ArchiveRepository”)}
make at the end of the mailboxes of account (name of theAccount) new mailbox with properties {name:(“ArchiveRepository/domain.of.list”)}
make at the end of the mailboxes of account (name of theAccount) new mailbox with properties {name:(“ArchiveRepository/domain.of.list/listname”)}
— etc etc

In Doug’s code functionality is achieved by:

— Find the month archive mailbox. If this does not
— exist, we create it.
try
set monthMailbox to (mailbox archiveMonth of yearMailbox)
on error
log “Creating ” & archiveMonth & ” mailbox”
if imapAccountName is “” then
make new mailbox with properties {name:mailboxName}
else
make at the end of the mailboxes of account imapAccountName new mailbox with properties {name:mailboxName}
end if
set monthMailbox to (mailbox archiveMonth of yearMailbox)
end try

Unfortunately this does not seem to be portable to all IMAP servers. My email server generates an error when I try to CREATE “ArchiveRepository/domain.of.list” while “ArchiveRepository” already exists and is not a container of other mailboxes.

The obvious solution is create the mailbox using the full path, all the way to the last mailbox that will not be a container of mailboxes but of messages. An example is below:

try
set rootMailbox to mailbox ArchiveRoot of theAccount
on error
display dialog “Creating ” & mailboxName & ” mailbox in ” & name of theAccount with icon 1
make at the end of the mailboxes of account (name of theAccount) new mailbox with properties {name:(mailboxName)}
set rootMailbox to mailbox ArchiveRoot of theAccount
end try
set ListDomainBox to my ReturnChildMailbox(rootMailbox, TheDomain, theAccount, mailboxName)
set ListnameBox to my ReturnChildMailbox(ListDomainBox, TheListName, theAccount, mailboxName)
set YearBox to my ReturnChildMailbox(ListnameBox, archiveYear, theAccount, mailboxName)
set QuarterBox to my ReturnChildMailbox(YearBox, Quarter, theAccount, mailboxName)
log “Box set to ” & name of QuarterBox as text move theMessage to QuarterBox

Where ReturnChildMailbox does the appropriate creation

on ReturnChildMailbox(ParentMailbox, childname, theAccount, FullPath)
tell application “Mail”
try
set ChildMailbox to (mailbox childname of ParentMailbox)
on error
display dialog “Creating ” & childname & ” mailbox in ” & name of ParentMailbox & return & FullPath with icon note
make at the end of the mailboxes of account (name of theAccount) new mailbox with properties {name:(FullPath)}
set ChildMailbox to (mailbox childname of ParentMailbox)
end try
end tell

return ChildMailbox
end ReturnChildMailbox

Maybe I’ll post the script at some point 😉

From the Waste of Time Dept.: hpss unable to bind to socket

This is for those folk in google land querying for "hpss Unable to bind to socket"

I am running a tiny appliance that is configured with Voyage linux. Its my always-on box that runs as web, mail, print, and file server. Between a update or two printing stopped working. A few minutes of investigation told me that something went wrong when starting /etc/init.d/hplip. It generated the following error:

Nov 3 19:22:39 tiny hpiod: 1.6.10 accepting connections at 2208…
Nov 3 19:22:40 tiny python: hpssd[24441] error: Server exited with error: Unable to bind to socket

Reinstalling cupsys, hplip, and foomatic did not fix this problem. 

It took me quite a while to figure out what was wrong: localhost did not resolve to 127.0.0.1. The reasons for this are manyfold but boil down to the fact that I try not to mess with the default configuration to much and that that default configuration happens to create an /etc/resolv.conf that points to opendns resolvers. Those do not resolve localhost to 127.0.0.1 but to their web-traffic-magnet address.

The fix: make sure that /etc/hosts existed with a mapping from  127.0.0.1 to localhost 

 

Credit Card , Domain Name, Spoofing and Phishing 

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. 

Updated April 8, 2012: html code and moved pictures to a different location

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.

Export Article

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

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.

  1. Click Add (+) at the bottom of the network connection services list, and then choose VPN from the Interface pop-up menu.
  2. 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.
  3. Enter the server address and the account name for the VPN connection.
  4. Click Authentication Settings, and enter the user authentication information you were given by the network administrator.
  5. 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". 

 

OpenFire, IPv6, and FreeBSD

 

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]

 

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

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.