Jürgen Pabel's Blog

Secure PIN entry and cheap RFID readers

2010-08-25T00:14:12+02:00

The German government will start issuing national ID cards equipped with RFID chips later on this year. One of the proclaimed scenarios is to use it with a RFID reader for identification and/or age verification on the Internet. To promote adoption the government will distribute one million USB reader devices for free upon request. One catch is that these reader devices are simple RFID reader devices - they lack essential security features like a build-in keypad for secure PIN entry. Rather, the PIN is entered into a software running on the computer via computer's keyboard and relayed into the RFID card reader. Any computer security expert will tell you that this is a fairly risky endeavour: the PIN might be intercepted during entry on the computer if malware is present on the computer.

Obviously, the question to ask is how can such reader devices be designed to be more secure and still be manufactured cheaply? Here's an idea: embed a USB host port and a simple microcontroller on the RFID reader device and connect your USB keyboard (assuming a non-laptop computer) to the reader device (instead of the computer's USB port). In normal operation mode, the reader device would relay all input from its attached keyboard to the computer's USB port; thus, the reader will act as a simple data relay. However, any time an application issues a request to the ID card and the user is asked to authenticate by entering their PIN than the reader device could choose to not relay key input to the computer but rather re-route (for lack of a better term) it to the RFID interface for authentication to the ID card.

I'm not going to delve into technical details right now, but I'm sure such a design would be resistant against PIN interception if implemented correctly. Leave some comments and I'll detail this idea further (multiple USB device classes, driver implementation aspects, etc) - I won't bother otherwise.

Alive and kickin

2010-08-13T13:03:01+02:00

Well, it's been a few days, weeks, months - I've been really busy with work lately, so that's my excuse for not blogging.

I've submitted a talk proposal to HashDays ("#days") 2010 and I am really happy that it got accepted. Now it's up to me to polish my Proof-of-Concept for FrozenCache into a release-worthy state.

Response to Solar Designers MoPS submission

2010-05-26T20:57:55+02:00

Great write-up about catcha's when implementing user authentication/management for PHP/web applications, especially because he explains why things should be done a certain way. The only aspect I am missing is why it is important to construct (especially) the credential verification logic as a combination of application logic and database query instead of just combining everything into a SQL query. I have seen constructs like

SELECT uid FROM users WHERE username='foo' AND password='bar'

(or any derivative that includes the hashed and/orstretched password value). The application logic would than only use the returned record for obtaining the uid of the (assumed to be correctly authenticated user). The core problem is that this approach combines both user record loading and user authentication into one operation (and also off-loads this task to the database). By separating the credential verification into two parts, one handled by the SQL layer and the other handled by the application logic, it becomes harder for an attacker to mount an attack on the authentication logic by exploiting a vulnerability in the SQL layer (assuming that whatever target the attacker is after can not be accomplished by exploiting such an SQL layer vulnerability itself).

Configuration Encryption Patch for Suhosin

2010-05-22T18:24:03+02:00

My submission for the Month of PHP Security was published today. I implemented a new feature for Suhosin which allows configuration values (any data actually) to be encrypted using an encryption key specified in the php.ini configuration file. In addition to the patch I've written an article explaining the necessity for encrypting passwords in confguration files - especially in enterprise environments.

SIGINT sneak preview

2010-05-21T18:03:46+02:00

You, my loyal blog readers, are the first to learn about my newest creation: CSS history hack based user tracking . Everyone else will have to wait until my presentation at SIGINT tomorrow (sorry, it'll be in german by request of the organizers).

CCC Pentabarf Password reset

2010-05-09T21:37:32+02:00

I had to reset my pentabarf password for the CCC, here's the confirmation E-Mail I received:

Dear ***,

Someone (probably you, from IP address 127.0.0.11)
requested a password reset.

To reset your password just follow the link where you can define a new
password:

<--snip-->

That's funny because 127.0.0.11 is a loopback IP address (originating from their own system).

By the way: http://events.ccc.de/sigint/2010/wiki/Fahrplan/events/3785.de.html (in german)

chumPod

2010-04-01T00:37:14+02:00

The chumPod is a music widget for the Chumby. This is no April's fools joke. Why would anyone create a music widget for the Chumby? Because I like to listen to some internet radio stations on my Chumby and always having to navigate through the chumby menus is very annoying. I would rather have that control "up front" as a widget. Sure, this does not exactly fit the chumby's "widget" paradigm - but it suits my needs.

The current version is barely more than a proof-of-concept. It looks rather ugly (I have no design skills at all) and doesn't yet have a configuration tool for widget configuration (internet radio stations are currently sort of hardcoded). I am working on implementing support for Firefly (or any other Roku Soundbridge Protocol compatible server).

The chumby widget page can be found here. The sourceforge project page is here. And the source code repository is located here.

Firefly crossdomain.xml plugin

2010-03-28T01:43:52+01:00

Firefly is an open-source media player (iTunes for the poor). I've implemented a plugin that serves up a crossdomain.xml file: this allows Flash "applications" to use Firefly (for streaming music).

The source code is here. Place it in the src/plugins folder of the firefly sources and compile it like so:

  gcc -shared -o crossdomain_xml.so -I.. -I../.. crossdomain_xml.c

Then copy the library to /usr/lib/mt-daapd/plugins/ (or wherever the plugins directory for your installation may be) and add the crossdomain_xml.so plugin to the "plugins" configuration directive in /etc/mt-daapd.conf (don't forget to restart firefly).

Google NativeClient on the server

2010-03-27T02:31:49+01:00

Well, I thought I had a novel idea while driving today; turns out someone else had already written (pretty much exactly) what I had in mind.

And yet another mod_dav_svn idea -- sort of

2010-03-21T00:40:41+01:00

I refrain from having subversion repositories for my personal documents on a public ("root") server. I rather keep them in repositories on my home network. I don't like the idea of a (constantly exposed) internet-server containing all my documents. That's why there should be a second line of defense in case such a system is hacked. The "obvious" solution would be to use a cryptographic filesystem on the server that has to be mounted before the repository is accessed. However, that approach introduces a whole slew of technical issues (only root can/should mount, has to be manually dismounted, ...). Why not instead implement a new (or extend an existing) SVN backend that provides such cryptographic capabilities? Unfortunately, it looks like this can't be implemented as a source code patch (instead of a plug-in or extension).

On a side note: I recently stumbled across this SQL backend for Subversion (sadly it hasn't been continued and looks incompatible with current releases).

Reverse DNS advertising

2010-03-12T16:01:17+01:00

A log entry from my blog's log file:

XXX.XX-get-oneprice-adsl-for-only-R169.cybersmart.co.za

That's funny (by the way: 169 Rand is roughly 16,50€ or 22,80US$).

Another mod_dav_svn idea

2010-03-10T21:57:02+01:00

Some online storage (WebDAV) services provide mechanisms to share specific resources with others easily: usually, a link can be generated that allows access to the specified resource within the online storage (but can't be used to access any other resources). That way it's easy to share documents without having to create user accounts, set passwords and apply the corresponding ACL settings. It would be pretty cool if such a feature were to be implemented in mod_dav_svn (actually, mod_dav might be the more suitable module for this).

On another note: SVNIndexXSLT might be a good way to implement HTML output containing RSS feed links for this idea. The benefit would be not having to patch mod_dav_svn's source code (search for "gen_html") and thus to create an independant module that builds upon mod_dav_svn.

Update: As it turns out, using the SVNIndexXSLT is a no-go because there is no practical way to determine the current URL using XSLT in that context: the items in the xml document lack the basepath and unparsed-entity-uri() is not implemented in TransforMiiX (Firefox's XSLT engine) for determining the basepath later on. Sure, using the HTTP referrer on the server-side should work for most use-cases, but that's too hackish for my taste.

Palm webOS Hot Apps mischief

2010-03-07T23:12:04+01:00

Too bad I didn't think of this earlier in the contest: the terms & conditions for the Palm webOS Hot App contest declare no restrictions about the type of app for the contest; I am sure that a "$5.000 Giveaway" app would have good changes of winning (by registering the most downloads). Of course, this money would only be paid if the app does win the contest itself (multiple winners should be drawn if this app would win any of the big $100.000 prizes).

Reverse DNS pseudomizer

2010-02-26T19:51:29+01:00

There's a debate here in Germany about whether an IP address is a piece of data that can (or could) identify a person. This is an important question for the IT industry in Germany because of our stringent data privacy laws: storing and/or processing personal data requires the person's (prior) agreement. The current headlines revolve around Google Analytics but the general question is whether the established procedure of logging IP addresses is in line with the law.

What if IP addresses are declared as personal data? Two questions twirl around in my head:

What about other uses of IP addresses (like in dynamically generated firewall rules)?
What's a practical alternative to logging IP addresses?

While my first question is in fact to be taken seriously - albeit it's sort of funny to think about the implications. Hoever, I don't have any further thoughts with respect to question #1. I've seen several academic papers in the past with respect to question #2 but can't currently locate them - with one exception: Ulrich Flegel's paper about pseudomizing Unix log files using a modified syslog daemon (which has additional pseudomizing aspects like unix usernames and the like). My main issue is that the deployment of such a solution would be rather involved for most environments. My (rather easy to deploy) suggestion is a pseudomizing reverse DNS server; the web server would need to be configured to not log IP addresses but rather the reverse DNS name of the visitor (which is a standard configuration option for most servers). However, most webserver admins (understandably) shy away from logging reverse DNS names because of the potential for delays incurred by unsuccessful reverse lookups. However, if a DNS server handling reverse lookups was deployed locally then performance wouldn't be an issue. If this reverse DNS server served not the real reverse DNS name but rather a pseudomized DNS name then all the sudden we would have solved those legal concerns. Well, not quite: of course the IP addreses would need to be stored within the reverse DNS pseudomizer itself; however, I am sure that there are ways to design and operate such a device in that it would be considered compliant to the law (ie: access restricted to a designated privacy officer).

A true HP-UX gem

2010-02-25T00:00:00+01:00

Yesterday I've stumbled across a tool Pit and I wrote a few years ago. In honor of his birthday I decided to devote a blog entry to this (don't worry: the technical details are quite interesting).

The scenario: we were facing issues in our production environment with a multi-process server application that binds an UDP port to a multicast address on HP-UX. Every now and than the system would stop processing messages sent to its multicast address. After quite some time we realized that this ocurred whenever one of the server applications processes terminated (ie: crashed). Since this server application was a service provider on the corporate/enterprise service bus it meant that that particular service was available in one less server (as in system) instance to the service bus whenever a process terminated. That could turn in to a real problem quickly, so we needed a solution that would allow a quick problem recovery until the real issue was fixed.

The problem: HP-UX 11.11 had a bug that didn't account for multiple "participants" (processes bound to the same multicast address). In other words: if you had multiple processes on the server that used the same multicast address and one of these processes terminates then HP-UX (incorrectly) instructed the network card to not listen for incoming packets to that multicast address any longer (well, the corresponding MAC address). The remaining server processes would keep on waiting for incoming packets but the network card just didn't want them any more. The theorectical solution looked easy: if a process bound itself on that multicast address then HP-UX would instruct the network card to listen to multicast packets again. The two obvious implementation alternatives weren't quite acceptable:

restart the entire process tree -> a restart took too long
start a dummy process that binds to the multicast address and puts itself to sleep (it must not terminate because that would reverse the intended effect) -> how many dummy processes would we have over the course of several months?

So, we needed another solution and we found one. HP-UX implements an interface named DLPI (Data Link Provider Interface), which allows low-level manipulation of network card state. We wrote a small tool that used DLPI to manually add the corresponding MAC address of the multicast address to the network card's MAC address for which it should accept packets. This tool was run via CRON every minute and the problem was "solved" until a fix became available for HP-UX (which happened with 11.20 if I remember correctly). Here's your birthday present, Pit: http://pastie.org/private/qeazuwrqnmar25hzo4reg (I am pretty sure you did't have the sources for that tool any more)