blueblog - by Christian J. Dietrich

DNS as carrier for botnet C&C seems to be getting popular. Concerning its usage as botnet C&C, DNS has not been seen so far. Additionally, in typical network environments, DNS (at least when destined for the preconfigured DNS resolvers) is usually one of the few protocols – if not the only one – that is allowed to pass without further ado. Thus, botnets using DNS as C&C benefit from the fact that currently there is no specifically tailored detection mechanism, which in turn, raises the probability for the botnet to remain undetected.

During our work on covert communication of botnet command and control channels, we analyzed Feederbot in some detail and monitored it over the last year. In this post, I will provide some insight on the C&C.
Not only Feederbot, but also Morto seems to be using DNS as carrier for its command and control channel.

But let us focus on Feederbot for now. Feederbot uses valid DNS syntax for its DNS messages. Messages from the C&C server to the bot are transmitted in the rdata field of a TXT resource record. The DNS requests have the several different schemes for the question domain name (qname), similar to the following where [CHUNK-ID] is an int >= 0, incremented by 1:

[50 bytes].[CHUNK-ID].[qdparam].0.f2.[TLD].   IN   TXT

The DNS responses typically carry one TXT RR in the answer section (sometimes repeated in the authority section) with a 220 byte string that is base64 encoded. Here is an example:

xMtwHYRyZu/z4QbhBKZIVWvPBfiuGn+jb1WQxtZN7PR9Wf0sfnAqxDOJD9LgmwfFaU

Go6fdtgZ0lIQyAx1VWJw+vzdHdxMpHu6xfMRq8sVSfqwPvI9TEIV8pkXw4P4TCSH05

BAO1LGPMQ+XD+TYLY2woxM1j06mCMhrNjWzI8WbmCBlj2/dpR73KBnDl/DRmheKWMJ

x2dUTp4iFMH4N9kXjeOYis

Once base64 decoded, the messages are still no real plaintext, because they are encrypted with RC4. Feederbot uses a variety of different RC4 encryption keys and even stacks RC4 encryption. A specific part of the DNS query domain name is used to transmit parameters for key derivation. As an example, one such parametrized key derivation function takes as input a substring of the query domain name, denoted as 'qdparam' in the example above. The value of the substring 'qdparam' is then RC4-encrypted with the (constant) string “feedme” (hence the name of the bot) and the result is used to initialize the RC4 decryption of the actual C&C message chunks. The stream cipher is used in a stateful manner, so that if a message chunk gets lost, decryption of all subsequent message chunks will fail. In addition, Feederbot’s C&C message chunks make use of cyclic redundancy checks to verify the decryption result. The CRC32 checksum preceeds message chunk payload and is not encrypted.

The fact that CRC32 checksums are used makes it comfortable to know whether decryption works or not. Interestingly, we have seen ANY as resource record type in some of the queries, too. In order to perform the DNS requests, the bot relies on Windows DNSAPI.dll::DnsQuery_W.

The following figure shows an important part of the disassembled RC4 initialization routine:


Well, the drawback of encryption is that you need a key and you better choose one that is easy to remember, such as:


So, what is the lesson we learn from Feederbot? Watch your DNS traffic!

Botnets have become one of the biggest security issues on the Internet imposing a variety of threats to Internet users. Advances in malware research have challenged botnet operators to improve the resilience of their C&C traffic. Partly, this has been achieved by moving towards decentralized structures (like P2P) or by otherwise obfuscating and even encrypting communication.

Recently, Christian Rossow and me, we looked into what we term covert communication, that is command and control communication which is hidden in what seems to be regular Internet traffic. We discovered and reverse engineered Feederbot, a botnet that uses DNS as carrier for its command and control. Using k-Means clustering and a Euclidean Distance based classifier, we correctly classified more than 14 million DNS transactions of 42,143 malware samples concerning DNS C&C usage. Interestingly, this analysis revealed yet another bot family with DNS C&C. In addition, we correctly detected DNS C&C in mixed office workstation network traffic.

Our paper dealing with DNS as carrier for botnet command and control channels got accepted at this year's EC2ND conference. I will be presenting the results at EC2ND which is going to take place in Gothenburg, Sweden, September 6-7 at Chalmers University.

BIND is the most prevalent DNS server software. Since CentOS 5.6, BIND is readily available in the more recent version 9.7.0 in the packages bind97*. Among others, a preconfigured chroot environment is provided. In order to use chrooted BIND, install the package bind97-chroot and make sure that ROOTDIR is correct in /etc/sysconfig/named:

[us@ns ~]# grep ROOTDIR /etc/sysconfig/named

ROOTDIR=/var/named/chroot

Note that a service named restart is required in case BIND was running beforehand.
In order to provide the chroot environment, certain files and directories are (re)mounted under /var/named/chroot

/etc/named on /var/named/chroot/etc/named type none (rw,bind)

/var/named on /var/named/chroot/var/named type none (rw,bind)

/etc/named.conf on /var/named/chroot/etc/named.conf type none (rw,bind)

/etc/named.rfc1912.zones on /var/named/chroot/etc/named.rfc1912.zones type none (rw,bind)

/etc/rndc.conf on /var/named/chroot/etc/rndc.conf type none (rw,bind)

/etc/rndc.key on /var/named/chroot/etc/rndc.key type none (rw,bind)

/usr/lib/bind on /var/named/chroot/usr/lib/bind type none (rw,bind)

/etc/named.iscdlv.key on /var/named/chroot/etc/named.iscdlv.key type none (rw,bind)

/etc/named.root.key on /var/named/chroot/etc/named.root.key type none (rw,bind)

Thus, for example /etc/named.conf is actually made available to the chrooted BIND and you as the admin just have to take care of one file. Previously, there used to be two named.confs, one inside the chroot environment and one outside. If you do not have a named.conf yet, I suggest you start using the named.conf template by Rob Thomas of Team Cymru.
Heading for DNSSEC validating resolution, the most important settings in named.conf are the following:

    // ****** DNSSEC relevant settings ****** //

    // Since 9.5 the default value is dnssec-enable yes;.

    // This statement may be used in a view or global options clause.

    dnssec-enable yes;

    // indicates that a resolver (a caching or caching-only name server)

    // will attempt to validate replies from DNSSEC enabled (signed) zones.

    // To perform this task the server also needs either a valid trusted-

    // keys clause (containing one or more trusted-anchors or a managed-keys

    // clause. Since 9.5 the default value is dnssec-validation yes;

    dnssec-validation yes;

    dnssec-lookaside auto;

    / Path to ISC DLV key /

    //bindkeys-file "/etc/named.iscdlv.key";

    / Path to root DNSSEC key /

    bindkeys-file "/etc/named.root.key";

As shown above, I changed the bindkeys-file statement to point to the root DNSSEC key instead of ISC's DLV root key. This is fine because by now there is a verifiable path to validate ISC's DLV root key (signed root, signed .ORG and signed isc.org and dlv.isc.org zones). Thus, ISC's DLV key does not need to be included any longer.

Please note that as of now (bind97-9.7.0-6.P2.el5_6.3), there is a bug in the init script of bind97 which has been acknowleged upstream. Basically, the root DNSSEC key is not mounted in the chroot environment. Until the bug will be fixed in the package, you should apply the fix (I also provided in the bug report):

# A possible fix is to include /etc/named.root.key in /etc/init.d/named, i.e.

# change the contents of the ROOTDIR_MOUNT variable in /etc/init.d/named from



ROOTDIR_MOUNT='/etc/named /etc/pki/dnssec-keys /var/named /etc/named.conf

/etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf /etc/rndc.key

/usr/lib64/bind /usr/lib/bind /etc/named.iscdlv.key'



# to



ROOTDIR_MOUNT='/etc/named /etc/pki/dnssec-keys /var/named /etc/named.conf

/etc/named.dnssec.keys /etc/named.rfc1912.zones /etc/rndc.conf /etc/rndc.key

/usr/lib64/bind /usr/lib/bind /etc/named.iscdlv.key /etc/named.root.key'

Finally you should test with a domain that has authoritative DNSSEC information. The answer must contain the AD flag.

[us@ns ~]# dig +dnssec @127.0.0.1 gov. ns

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-6.P2.el5_6.2 <<>> +dnssec @127.0.0.1 gov. ns

; (1 server found)

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14572

;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1



;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags: do; udp: 4096

;; QUESTION SECTION:

;gov.                           IN      NS



;; ANSWER SECTION:

gov.                    172800  IN      NS      b.gov-servers.net.

gov.                    172800  IN      NS      a.gov-servers.net.

gov.                    172800  IN      RRSIG   NS 7 1 172800 20110609040023 

20110604040023 43879 gov. FnygljkPqlL9Q08CX5lixJ7O5bB6ysM...

Part of a clean DNS configuration is to maintain a mapping from IP addresses to hostnames. Especially in email exchange, many mail servers require that the sender's IP address can be looked up in DNS and e.g. maps to a hostname. You can easily test this using the tool dig which is usually part of bind-utils:

$  dig  -x 80.67.18.126

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19989

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0



;; QUESTION SECTION:

;126.18.67.80.in-addr.arpa.     IN      PTR



;; ANSWER SECTION:

126.18.67.80.in-addr.arpa. 86400 IN     PTR     mxlb.ispgateway.de.

The listing shows the lookup for a PTR record of (one of) the mail server's IP address(es) of my domain. dig provides the -x flag which behind the scenes makes a query for 126.18.67.80.in-addr.arpa. of resource record type PTR. Equivalently, you can issue 'dig 126.18.67.80.in-addr.arpa. PTR'. As we can see from the output above, the IP address 80.67.18.126 maps to the hostname mxlb.ispgateway.de. (which in turn maps to 80.67.18.126 when querying for an A RR type).

In order to be able to provide reverse mappings for a set of IP addresses that have been assigned, there should be a delegation (or referral) from the authoritative entity which assigned the IP addresses. Usually you will want to have CIDR ranges of IPv4 addresses delegated. Thus, let's assume the upstream ISP takes care of the whole /24 network 1.2.3.0/24 (i.e. 1.2.3.0-1.2.3.255) and the subnet IP address range 1.2.3.32/27 (i.e. 1.2.3.32-1.2.3.63) should be delegated from the authoritative (upstream ISP) nameserver A to (your) nameserver B. The following configuration snippets provide an example configuration for BIND and illustrate the required steps.

Thus, A needs to be configured to delegate the DNS entries concerning the IP addresses 1.2.3.32/27 to the nameserver B as follows:

; depending on your style of zone files, you might not have an $ORIGIN in them at all

$ORIGIN 3.2.1.IN-ADDR.ARPA.

@            IN  SOA   ns1.A.com. dnsadmin.A.com. (

                              2011052501; serial number

                              1h             ; refresh after

                              1h             ; retry update after

                              2w             ; expire after

                              1h             ; negative caching TTL)

              IN  NS      ns1.A.com.

              IN  NS      ns2.A.com.



; here go PTR records for the IP address range 1.2.3.0-.31 which is not delegated to B

1            IN  PTR   some.absolute.hostname.example.com.

...

31           IN  PTR   note.that.relative.names.dont.make.sense.here.



; here goes the referral for the subnet 1.2.3.32/27 to B's name server(s)

32/27         IN  NS  ns1.B.com.

32/27         IN  NS  ns2.B.com.    ; in case B has a second NS



; Now comes an important part. the above statement does not suffice to refer queries to B's name server.

; In addition, we also have to define CNAMEs for ALL IP addresses in the subnet and map them to

; the referred domain 32/27.

33            IN  CNAME   33.32/27.3.2.1.IN-ADDR.ARPA.

; or alternatively

33            IN  CNAME   33.32/27

....

62            IN  CNAME   62.32/27  ; keep going from 33 to 62...

; ...or alternatively use the $GENERATE macro of BIND 8.2+

$GENERATE 33-62 $ CNAME $.32/27

Note that we could have chosen ANY arbitrary name instead of 32/27 for the CNAME targets as well as the referral (one could even refer outside the in-addr.arpa tree). However, RFC 2317 recommends the above scheme (for good reason).

On the "target" nameserver B, the zone looks similar to:

$ORIGIN 32/27.3.2.1.IN-ADDR.ARPA.

@            IN  SOA   ns1.B.com. dnsadmin.B.com. ( ... )

              IN  NS      ns1.B.com.

              IN  NS      ns2.B.com.



; provide the PTR mapping for the IP addresses 1.2.3.32-.63 (maybe omit first and 

; last as they are network and broadcast addresses).

33            IN  PTR   host33.b.example.com.

....

62            IN  PTR   web.example.com.



; alternatively use the $GENERATE macro of BIND 8.2+

$GENERATE 33-62 $ PTR host$.b.example.com.

The configuration of the zone on the nameserver B is something like:

...

    zone "32/27.3.2.1.in-addr.arpa" in {

      type master;

      file "data/1.2.3.32_27.reverse.zone";

    };

...

Testing the configuration
Here are some commands using dig in order to test the configuration:

; query one of the PTRs at B's nameserver

dig +norecurse  @[nameserver-of-B]  33.32/27.3.2.1.in-addr.arpa  PTR



; query A's nameserver for the exact referral

dig +norecurse  @[nameserver-of-A]  32/27.3.2.1.in-addr.arpa  ANY



; query A's nameserver for one of the PTRs

dig +norecurse  @[nameserver-of-A]  33.32/27.3.2.1.in-addr.arpa  PTR

dig +norecurse  @[nameserver-of-A]  33.3.2.1.in-addr.arpa  PTR



; query one of the PTRs starting at the root

dig -x 1.2.3.33

dig +trace -x 1.2.3.33

Last week, Kryptotag and SPRING took place at HGI in Bochum. It turned out to be a very interesting event, although unfortunately, I could not stay very long. My talk dealt with how Transport Layer Security with RSA-secured Pre-Shared Keys is used in the eID Online Authentication of the new German ID card. I provided a short recap on the default RSA key exchange and the plain Pre-Shared Key variant before outlining the difference to the RSA-PSK variant. My slides are available here.

Since November 2010, the new German electronic ID card provides a facility to perform an online remote authentication of the ID card holder. This method is called eID online authentication and is defined in the Technical Guideline TR-03110 of the Federal Office for Information Security. As part of the eID online authentication, personal data can be transmitted from the electronic ID card to its counterpart, the eID server. All data transmitted between the eletronic ID card and the eID server is supposed to be subject to secure messaging.

As the eID online authentication is specifically tailored to be used in web applications, the secure messaging channel between the eID card and the eID server is mapped to the Security Assertion Markup Language (SAML) and uses several TLS channels (Transport Layer Security, RFC 5246). In order to prevent man-in-the-middle attacks, the TLS channels are intertwined with the Terminal Authentication. This binding is realized by two aspects, one of them being the fact that special cipher suites are used which combine X.509 certificate based peer authentication with pre-shared keys. These cipher suites are termed TLS-RSA-PSK and defined in RFC 4279.

I implemented one of the TLS-RSA-PSK cipher suites as a patch to openssl-1.0.0c. This patch is EXPERIMENTAL. Apply it like so:

tar xvzf openssl-1.0.0c.tar.gz

cd openssl-1.0.0c

patch -p1 -i ../openssl-1.0.0c.tls-rsa-psk.patch

IMPORTANT NOTE: This patch is provided "as is". See LICENSE.txt for details.

Testing TLS-RSA-PSK
You can test locally whether your openssl with TLS-RSA-PSK works as follows. Make sure that you actually call the currently generated openssl binary (in the apps directory):

# launching the server

openssl s_server \

    -psk c033f52671c61c8128f7f8a40be88038bcf2b07a6eb3095c36e3759f0cf40837 \

    -key privkey.pem \

    -cipher RSA-PSK-AES256-CBC-SHA \

    -debug -state



# launch the client

openssl s_client -connect localhost:4433 \

    -psk c033f52671c61c8128f7f8a40be88038bcf2b07a6eb3095c36e3759f0cf40837 \

    -cipher RSA-PSK-AES256-CBC-SHA \

    -debug -state

You should then be able to pass data back and forth between the server and the client. Additionally, I have provided transscripts of what it looks like if it works. There is a server log and a client log.

I gave a short interview to Sat.1 today about the technical skills needed in order to implement a system for online bets. The interview was broadcast as part of a short report on a case where maybe online fraud was involved, though this is still to be clarified.
The video interview can be found online here: http://www.sat1nrw.de/Archiv/Illegales-Gluecksspiel/441d2794/.

Yes, Windows is far from being an enjoyable LaTeX editing base. However, every once in a while, you will find yourself urged to edit LaTeX under Windows. Thus, I compiled a few steps in order to have a somewhat usable LaTeX editing environment. I use MiKTEX in combination with Texmaker (both free). Texmaker has a builtin PDF viewer and an IDE-style builtin compile initiator. As often, it is the small details that make the difference. I dislike using an external program as PDF viewer that locks the .pdf-file and prevents from successful re-compilation. As a consequence you have to close the PDF viewer manually before each and every compile. Texmaker's builtin PDF viewer does not lock the pdf-file and thus re-compilation works like a charm. Furthermore, the -synctex=1 option to pdflatex enables the PDF viewer to jump to the right position in the LaTeX source upon a right-click. Even if you have your own special series of commands for compilation, you can recreate them in the options of Texmaker. I use the following user-defined quick build command in the options (remove line breaks, leave the pipes):

bibtex %|

pdflatex -synctex=1 -interaction=nonstopmode %.tex|

pdflatex -synctex=1 -interaction=nonstopmode %.tex|

"C:/Program Files/Adobe/Reader 9.0/Reader/AcroRd32.exe" %.pdf

Note that Texmaker uses the internal PDF viewer even though Acrobat's Reader is supposed to be called as last step (bug? feature?). All in all, in my eyes, Texmaker is a great LaTeX editor.

CentOS is a really fine platform for professional Linux servers which is - among others - characterized by stable software releases. However, especially in a research environment every once in a while you need a recent version of a software. CentOS ships with Gnuplot 4.0.0 but I need Gnuplot >=4.4. In case others need this, too, here are my compile instructions:

# make sure your system is uptodate

yum clean all

yum check-update

yum update



# based on a minimal installation, you need some packages in order to compile, I suggest

yum install gcc gcc-c++ make libX11 xauth

yum install cairo-devel pango-devel freetype-devel gd-devel



cd /usr/local/src/

wget http://sourceforge.net/projects/gnuplot/files/gnuplot/4.4.2/gnuplot-4.4.2.tar.gz/download

tar xzf gnuplot-4.4.2.tar.gz 

cd gnuplot-4.4.2

less INSTALL



# start compiling. I usually install self-compiled stuff at /opt/[PKG-NAME]

./configure --prefix=/opt/gnuplot442

make

# make sure the shipped version of gnuplot is removed (this is probably not necessary but prevents version mix-up)

yum remove gnuplot

make install



# you might want to add a symlink

ln -s /opt/gnuplot442/bin/gnuplot /usr/bin/gnuplot

As posted before, we have done an analysis of the remaining risks of the new German ID card (neuer Personalausweis, nPA) conducted by the German Federal Ministry of the Interior (Bundesinnenministerium). In mid October 2010, we published the summary of our study, presenting the key findings of the remaining risks (in German) when using the eID functionality via the Internet.

As the summary is only available in German, I will try to sum up the key findings in English here. First of all, we have to state that we analyzed the eID functionality only (neither the sovereign identification with biometry etc. nor the signature function). Thus, you may compare the target of the eID function to what usually is achieved using username and password authentication today. However, the eID function has mutual authentication builtin. This is one of the biggest advantages compared to "classic" username/password authentication where the server side is - if at all - only authenticated by its SSL/TLS certificate (ever heard of phishing?). Furthermore, the nPA requires a secret PIN before it can be used which effectively turns it into a two-factor-authentication mechanism. Thus, the security level of the eID function can be regarded much higher than classic username/password authentication.

There is always two faces of the same coin, so what ARE the remaining risks? We found that the card reader category B (Basisleser) poses a certain threat: Malware on the user's computer may - under certain circumstances - misuse the eID function of an nPA. As the secret PIN must be entered via the computer's keyboard when using Cat-B card readers, a keylogger may easily catch the PIN. Note that this only works with Cat-B card readers, not with the higher class card readers Cat-S (Standardleser) or Cat-K (Komfortleser). For more details, see our summary. A list of certified card readers is available online.

On 24th of August, the German TV program ARD plusminus announced that in cooperation with Chaos Computer Club, security flaws were found in the Online Authentication functionality of the new German ID card to be issued in November 2010. This caught some media attention and people now wonder: what is the impact?

First of all, let me clarify some aspects on the usage of the new German ID card (nPA). The nPA combines 3 distinct functionalities in one card. First, the sovereign function of the ID card, i.e. the authentication of a person in question is what people know from the current ID card. The nPA contains biometrics features in form of fingerprints to support this and only the sovereign function. Second, the online authentication serves as a means to communicate personal data from the chip to a service provider. This makes it possible to open a bank account or register a vehicle online, without the need for additional offline authentication. The third functionality is optional and provides digital signatures according to the German Signaturgesetz.

The security flaw referenced above targets the online authentication function in combination with a specific card reader of class CAT-B according to BSI TR 03119, the standard document for categories of card readers for the nPA. Due to the fact that the user has to enter the secret PIN via the computer keyboard when using CAT-B card readers, malware such as keylogging trojans can intercept the PIN. We found this in experiments ourselves. Knowing the PIN, the trojan might then remote control the nPA (which must be on or near the card reader) and perform an online authentication in the background, possibly without the user's notice. However, the personal data that is transmitted as part of the online authentication is not subject to interception.

Possible means to prevent this kind of flaw is to use a card reader of higher categories, such as Cat-S or Cat-K (according to BSI TR 03119). Those card readers have a pinpad to enter the PIN and keyloggers on the host computer do not interfere with these pinpads. Furthermore, even Cat-B card readers might be provided with visual or aural indicators that tell the user whenever an online authentication starts.

For more information on the German ID card, see my blog category. For news and statements in German, see also https://www.internet-sicherheit.de.

libsvm is one of the most famous SVM implementations. It can be used with OpenMP in order to parallelize computation (see its FAQ). Using CentOS 5.5 and libsvm2.91, this is how to do it:

# make sure the necessary packages are installed
yum install gcc44 gcc44-c++ gmp libstdc++44-devel glibc-devel
cd /usr/local/src
wget libsvm-2.91.... # from its website
tar xvzf libsvm-2.91.tar.gz
cd libsvm-2.91

# adapt the Makefile as follows
diff -crB Makefile Makefile.orig
** Makefile 2010-07-21 11:09:47.000000000 +0200
--- Makefile.orig 2010-07-21 11:09:42.000000000 +0200
**************
** 1,5 ****
! CXX = g++44
! CFLAGS = -Wall -Wconversion -O3 -fPIC -fopenmp
SHVER = 1

all: svm-train svm-predict svm-scale
--- 1,5 ----
! CXX ?= g++
! CFLAGS = -Wall -Wconversion -O3 -fPIC
SHVER = 1

all: svm-train svm-predict svm-scale

# adapt svm.cpp as follows
diff -crB svm.cpp svm.cpp.orig
** svm.cpp 2010-07-21 10:58:22.000000000 +0200
--- svm.cpp.orig 2010-07-21 10:55:25.000000000 +0200
**************
** 1267,1273 ****
int start, j;
if((start = cache->get_data(i,&data,len)) < len)
{
- #pragma omp parallel for private(j)
for(j=start;j data[j] = (Qfloat)(y[i]*y[j]*(this->*kernel_function)(i,j));
}
--- 1267,1272 ----
**************
** 2487,2493 ****
int l = model->l;

double *kvalue = Malloc(double,l);
- #pragma omp parallel for private(i)
for(i=0;i kvalue[i] = Kernel::k_function(x,model->SV[i],model->param);

--- 2486,2491 ----

# compile
make
# install
cp svm-train svm-predict svm-scale /usr/local/bin/

# set environment variable (exact syntax depends on the shell used), e.g. on a 4 core system
export OMP_NUM_THREADS 4


...and run libsvm as usual.

I updated my App on Richard Paul Lohse's work "15 Farbreihen" which is available on my homepage at http://www.cj2s.de/lose-yourself/. The tooltip help texts have been translated into English and I released my thesis titled 'farbflaechenbilder' on that matter (unfortunately only in German). The thesis was written as part of the Junge Nacht (young night) of museum kunstpalast in Düsseldorf where I worked as a guide through the exhibition on color field paintings.
Have spare time? Want some distraction? Just open my Lohse-Yourself App and click an the button 'random' to see some inspiring color combinations. Enjoy!

On popular demand, I published my (German) Master Thesis titled 'eID Online Authentisierung mit dem neuen elektronischen Personalausweis nPA'. It deals with the electronic identification functionality which will be implemented in the new German ID card that will be issued from November 1st, 2010 onwards. As the thesis was conducted by the German Ministry of the Interior, parts of it are still classified and thus not included in the public version of the thesis. However, it should give fairly detailed insights into the overall technology, major algorithms used as well as security contexts. Below you will find a summary of the thesis (unfortunately only in German). Please note that the thesis was written in 2008, thus some technical guidelines, especially concerning EAC, have changed since then (some changes even due to my thesis' results).

Zusammenfassung/Summary
Zunächst soll diese Master Thesis die Notwendigkeit und die Vergleichbarkeit des Sicherheitsniveaus zwischen dem physikalischen und dem elektronischen Ausweisdokument aufzeigen. Darüber hinaus soll eine Implementierung der Authentisierungsfunktion bzw. Online-Authentisierung des nPA für die Anwendung über das Internet – die erste ihrer Art – ihre Machbarkeit demonstrieren. Im Rahmen der Arbeit werden also sowohl die notwendigen Komponenten aller teilnehmenden Parteien (eID Authentication Server, Bürgerclient etc.) vorgestellt, die für eine Realisierung benötigt werden als auch tatsächliche Implementierungen dieser Komponenten beschrieben und gefertigt. Der Ablauf der Online-Authentisierung soll zusätzlich aus der Perspektive des Anwenders dokumentiert werden. Hierbei sind wichtige Schritte detailliert zu beschreiben.

Notwendigkeit eines elektronischen Personalausweises
Grundsätzlich wird in diesem Kontext die Frage nach der Notwendigkeit eines neuen, elektronischen Personalausweises aufgeworfen. Es läge nahe, die Notwendigkeit mit mangelnder Fälschungssicherheit des bisherigen Personalausweises zu begründen. Betrachtet man dies jedoch im Detail, so ist keine mangelnde Fälschungssicherheit feststellbar. Im Gegenteil – die deutschen Ausweisdokumente, also sowohl der Reisepass als auch der Personalausweis gehören weltweit zu den am schwersten fälschbaren Dokumenten.
Betrachtet man jedoch die Möglichkeiten, die derzeit für eine Identifikation und eine Authentisierung anhand von Ausweisdokumenten über das Internet zur Verfügung stehen, so wird klar, dass hier keine sichere Lösung existiert. Der elektronische Personalausweis soll diese Lücke mit Hilfe der sog. Authentisierungsfunktion nun schließen und eine sichere Authentisierung über das Internet ermöglichen.

Die Online-Authentisierung des nPA
Die Authentisierungsfunktion ermöglicht eine sichere Übertragung von Daten, die auf dem Ausweis gespeichert sind an einen Dritten. Während die Identifikation mit Hilfe von biometrischen Merkmalen (und somit auch der Zugriff auf diese) lediglich für den hoheitlichen Anwendungsbereich vorgesehen ist, soll die Authentisierungsfunktion sowohl für eBusiness als auch eGovernment verfügbar sein. Spezielle Teilfunktionen der Authentisierungsfunktion sind die Altersverifikation sowie ein sektorspezifischer Identifikator. Die Altersverifikation kann als Jugendschutzfunktion eingesetzt werden und der sektorspezifische Identifikator bietet ein eindeutiges Benutzerkennzeichen.
Mit Hilfe der Authentisierungsfunktion können also auf sichere Art und Weise, Attribute an einen Dienstanbieter übermittelt werden. Die Bezeichnung Attribute umfasst dabei nicht notwendigerweise ausschließlich explizite personenbezogene Angaben wie Vor- und Nachname, sondern auch relative Aussagen, wie z.B. "die Person ist älter als 18 Jahre". Im Rahmen der Registierung in einem Webshop ist vorstellbar, dass anstelle der manuellen Eingabe der personenbezogenen Daten, z.B. der volle Name und die Adresse, diese mit der Authentisierungsfunktion aus dem nPA ausgelesen werden. Der Dienstanbieter hat dann die Gewissheit, dass die Daten authentisch und integer sind.

Implementierung der Online-Authentisierung
Die Authentisierungsfunktion baut auf dem erweiterten Zugriffsschutzmechanismus Extended Access Control (EAC) auf. Das vom Bundesamt für Sicherheit in der Informationstechnik (BSI) spezifizierte Verfahren EAC sichert die Authentizität und Integrität der Daten sowohl in gespeicherter Form als auch während der Übertragung. Es besteht aus den 3 Protokollen Password Authenticated Connection Establishment (PACE), Terminal Authentication und Chip Authentication. Kernbestandteile von Extended Access Control sind symmetrische und asymmetrische (Elliptische-Kurven-)Kryptographie, eine globale Public Key Infrastruktur sowie die Verwendung von abstreitbaren Challenge-Response-Verfahren.

PACE ist ein Verfahren zur Freischaltung des Chips durch ein Lesegerät. Mit Hilfe einer sechsstelligen PIN, die als Passwort fungiert, wird einem Lesegerät der Zugriff auf den Funkkanal zu einem Chip, z.B. dem nPA, gestattet. Aus kryptographischer Perspektive handelt es sich dabei um eine verschlüsselte Diffie-Hellman-Schlüsseleinigung. Im Rahmen der sog. Terminal Authentication prüft der Chip mit Hilfe eines Challenge-Response-Verfahrens die Zugriffsberechtigungen des Lesegeräts (Terminal). Die Chip Authentication ist ein Verfahren, das genutzt wird, um die Authentizität des Chips zu prüfen. Hierbei werden implizit die Daten, die ein Chip liefert authentisiert. Aus kryptographischer Sicht handelt es sich um eine Diffie-Hellman-Schlüsseleinigung mit statischem Chip-Schlüssel. Nach Abschluss der Chip Authentication ist ein verschlüsselter Ende-zu-Ende-Kanal etabliert.

Berechtigungszertifikat oder Terminal Certificate
Das Terminal Certificate ist ein wichtiger Bestandteil der Authentisierung zwischen nPA und EAS. Es enthält neben dem öffentlichen Schlüssel des EAS die Berechtigung des EAS. Die Berechtigung gibt an, welche Felder des nPA durch den EAS ausgelesen werden dürfen. Das Terminal Certificate muss durch einen gültigen Document Verifier signiert worden sein. Auf diese Weise kann ein nPA sicherstellen, dass nur die Inhalte der Datenfelder an den EAS gesendet werden müssen, für die der EAS auch tatsächlich authentifiziert ist. Im Rahmen der Terminal Authentication wird dem Benutzer ein Dialog angezeigt, der die Kenndaten des Terminal Certificate visualisiert. Dieser Dialog zeigt den Zertifikatsinhaber, die Gültigkeit des Zertifikats, die Zugriffsberechtigungen auf die auszulesenden Attribute, einen Verweis auf die zuständige Datenschutzaufsichtsbehörde sowie den Verwendungszweck.

Schwachstellen und Angriffe
Angriffe auf die Online-Authentisierung des nPA, bei denen Kernkomponenten durch bösartige Instanzen ausgetauscht werden scheitern in der Regel. Da eine beidseitige Authentikation in den Endpunkten stattfindet, kann eine bösartige Komponenten entlarvt werden und das Auslesen der Daten aus dem nPA scheitert. Auch ein Angriff auf die Transportverschlüsselung und -integrität wird üblicherweise erfolglos verlaufen, da hier stabile Kryptographie – wie z.B. AES und Elliptische-Kurven-Kryptographie (ECDSA und ECDH) – zum Einsatz kommt.
Verbleibende Ansatzpunkte für Angriffe sind

• die Verifikation des Terminal Certificate durch den nPA


• Man in the Middle Angriffe sowie


• das An-/Abwählen von Attributen im Dialog des Berechtigungszertifikats.

Die Verifikation des Terminal Certificate erfolgt im nPA. Der nPA hat eine logische Uhr, die anhand von erfolgreichen Verifikationen in der Vergangenheit synchronisiert wird. Je seltener ein nPA benutzt wird (konkreter: erfolgreich authentisiert), umso größer die Abweichung der logischen Uhr des nPA von der Realzeit. Sobald das Schlüsselmaterial eines vormals legitimen EAS sowie ein in Bezug auf die Realzeit abgelaufenes Terminal Certificate für einen Angreifer verfügbar wird, könnte ein nPA mit hoher Abweichung seiner logischen Uhr den Zugriff eventuell fälschlicherweise zulassen. Auch die Abfrage von Sperrlisten kann nicht verlässlich implementiert werden, da Socket-Operationen Teil des Betriebssystems des Clients und nicht des nPA sind. In der Konsequenz könnte der Gültigkeitszeitraum von Terminal Certificates sehr kurz ausfallen, z.B. lediglich 24 Stunden. Sobald Missbrauch festgestellt wird, kann auf diese Weise durch eine Verhinderung der Neuausstellung eines Zertifikats reagiert werden. Trotzdem gilt: Je häufiger ein nPA zur Authentisierung genutzt wird (und je geringer damit die Abweichung von Realzeit und logischer Uhr sind), umso geringer ist das Erfolgsrisiko für einen solchen Angriff. Beschreibungen zu den restlichen Ansatzpunkten sind ebenfalls Teil der Master Thesis.

See the full thesis for details.

Even botnet operators know the fine advantages of Linux servers: Some (if not most) operate their main C&C servers as Linux hosts. When reading through server logs full of SSH authentication failures due to bruteforce scans, I sometimes wonder, do those C&C servers of the botmasters also get these annoying attempts? However...

I have used fail2ban in order to prevent from these attacks for years. fail2ban scans the log files in order to identify bruteforce scans and bans the source IP addresses using iptables. If you use CentOS, you can install fail2ban from the rpmforge repository like so:

yum --enablerepo rpmforge install fail2ban.noarch

After installation, configure fail2ban must be configured. Change the parameter ignoreip in the config file /etc/fail2ban/jail.conf to match the desired IP address ranges that shall never be blocked, e.g.:

ignoreip = 127.0.0.1 192.168.0.0/24 172.16.0.0/24 10.0.0.0/18

Furthermore, the section ssh-iptables must be enabled. NOTE: Change the email address! You probably want to change the sender email address, too.

[ssh-iptables]

enabled  = true

filter   = sshd

action   = iptables[name=SSH, port=ssh, protocol=tcp]

           sendmail-whois[name=SSH, dest=RECEIVER@DOMAIN, sender=fail2ban@HOSTNAME]

logpath  = /var/log/secure

maxretry = 5

If someone else than root shall get the mail, change the directive dest in /etc/fail2ban/action.d/mail.conf.

Finally, make sure that it is enabled in the correct runlevels:

chkconfig fail2ban on

service fail2ban start