Vorwahlbot

Online Melderegisterauskunft in Düsseldorf macht schlechten Eindruck

Mir war nicht ganz klar, welche persönlichen Daten das Einwohnermeldeamt an wen weitergeben darf. Ich bin nach etwas Recherche auf diese Aktion der PIRATEN gestoßen, die dazu auffordern, der Weitergabe der eigenen Daten bei den Meldeämtern zu widersprechen. Viele Meldeämter geben die Daten nämlich inzwischen jedem! der zahlt. Dem kann man nur durch einen Widerspruch entgehen.

Daten von den Meldeämtern werden weitergegeben an:

Staatliche Behörden, bei berechtigtem Interesse im Rahmen der Amtshilfe 

Also z.B. Polizei, Staatsanwaltschaft, statistische Ämter, etc.

die GEZ

Die Brüder kennen wir ja schon zur Genüge.

Parteien, Wählergruppen und anderen Trägern von Wahlvorschlägen im
Zusammenhang mit Parlaments- und Kommunalwahlen; § 35 Abs.1 MG NRW

Um die hübsche Hochglanz-Wahlwerbung zu erhalten.

an Antragsteller und Parteien im Zusammenhang mit Volksbegehren und
Volksentscheiden sowie mit Bürgerentscheiden; § 35 Abs.2 MG NRW

Um Hochglanz-Entscheidungshilfen bei den häufigen Volksabstimmungen zu erhalten.

im Wege des automatisierten Abrufs über das Internet; § 34 Abs.1b MG NRW

Das ist der Punkt, der mir bisher nicht bekannt war. Über ein Internetportal kann
jeder, der einige Kenndaten einer Person kennt automatisiert über das Internet
Meldeauskünfte einholen. Die Abfrage kostet zur Zeit 4 Euro pro Datensatz in Düsseldorf.

Das Meldegesetz NRW sagt an dieser Stelle:

https://recht.nrw.de/lmi/owa/br_bes_text?anw_nr=2&gld_nr=2&ugl_nr=210&bes_id=4655&aufgehoben=N&menu=1&sg=

§ 34 Abs.1b MG NRW
(1b) Soll der Abruf über das Internet ermöglicht werden, ist sicherzustellen, dass das Antragsverfahren und die Auskunftserteilung in verschlüsselter Form erfolgen. Die Eröffnung des Zugangs ist öffentlich bekannt zu machen. Ein Abruf ist nicht zulässig, wenn der Betroffene dieser Form der Auskunftserteilung widersprochen hat. Die Meldebehörde hat spätestens einen Monat vor der Eröffnung des Internetzugangs durch öffentliche Bekanntmachung auf das Widerspruchsrecht hinzuweisen. Im Übrigen gilt § 35 Abs. 6 Satz 2 entsprechend.

Ein Widerspruch gegen die Weitergabe der Daten ist durch das Ausfüllen eines Formulars möglich. Für Düsseldorf findet sich dieses hier: https://formulare.duesseldorf.de/forms/frm/7PRPfAZH5gQA8Ja8AkNGaH1rNpDcHR3 Dieses kann kostenlos in Bürgerämtern abgegeben werden. Danach ist kein Onlinezugriff auf die eigenen Daten mehr möglich. Anscheinend werden die Datenzugriffe regional von den jeweiligen Städten und Kreisen organisiert.

Auf meine Nachfrage bei der (sehr freundlichen) Sachbearbeiterin im Bürgerbüro hin, konnte
man mir leider nicht die URL des Abfrageportals mitteilen. Eine kurze Recherche hat mich dann aber schnell auf diese Seite der Stadt Düsseldorf geführt:

https://www.duesseldorf.de/emra/emra.jsp?stadt=D%FCsseldorf&art=Stadt

Das Portal machte technisch gelinde gesagt einen sehr zweifelhaften Eindruck.
Zunächst einmal scheint es keinerlei Captcha oder ähnliches zu geben. Eine Massenabfrage scheint also mit entsprechenden Skripten möglich zu sein.

Außerdem verabschiedete sich die Webapplikation bei meiner Testabfrage mit folgender Tomcat Fehlermeldung, da ich keine Cookies aktiviert hatte:

Dies lies mich dann doch zunehmend an der Professionalität einer Anwendung zweifeln, die Zugriff auf die Daten aller Bürger der Stadt bietet. Ein Skript sollte nicht abstürzen, wenn Voraussetzungen am Rechner des Benutzers nicht gegeben sind (in diesem Fall mein fehlender Cookie). Skript-Fehlermeldungen von Webservern, die sich im produktiven Einsatz befinden nicht zu deaktivieren ist fahrlässig, da sie viel über die verwendete Systemumgebung verraten können. Zumal man bei jsp (wie im Screenshot oben) je nach Konfiguration des Servers auch noch Kommentare des Programmierers und Quelltextschnippsel dazu bekommt. Hier wurde geschlampt. An einer Schnittstelle zu persönlichen Daten sollte das nicht passieren.

Aufhorchen ließ mich auch die benutze Tomcat Version, welche in der Fehlermeldung auch unten auftaucht. (Apache Tomcat/6.0.24) Dies ist eine ältere Version des Webservers vom 21.01.2010. Aktuell ist die Version 6.0.33. Der Melderegister-Server wurde 4 Versionen lang nicht aktualisiert. Schaut man sich die Sicherheitslücken an, die in diesen letzten Versionen behoben wurden, wird es langsam ungemütlich. Der Server befindet sich offensichtlich nicht im bestmöglichen Zustand:

http://tomcat.apache.org/security-6.html

Fixed in Apache Tomcat 6.0.33	released 18 Aug 2011

    Moderate: Multiple weaknesses in HTTP DIGEST authentication CVE-2011-1184

    The implementation of HTTP DIGEST authentication was discovered to have several weaknesses:

        replay attacks were permitted
        server nonces were not checked
        client nonce counts were not checked
        qop values were not checked
        realm values were not checked
        the server secret was hard-coded to a known string

    The result of these weaknesses is that DIGEST authentication was only as secure as BASIC authentication.

    This was fixed in revision 1158180.

    This was identified by the Tomcat security team on 16 March 2011 and made public on 26 September 2011.

    Affects: 6.0.0-6.0.32

    Low: Information disclosure CVE-2011-2204

    When using the MemoryUserDatabase (based on tomcat-users.xml) and creating users via JMX, an exception during the user creation process may trigger an error message in the JMX client that includes the user's password. This error message is also written to the Tomcat logs. User passwords are visible to administrators with JMX access and/or administrators with read access to the tomcat-users.xml file. Users that do not have these permissions but are able to read log files may be able to discover a user's password.

    This was fixed in revision 1140071.

    This was identified by Polina Genova on 14 June 2011 and made public on 27 June 2011.

    Affects: 6.0.0-6.0.32

    Low: Information disclosure CVE-2011-2526

    Tomcat provides support for sendfile with the HTTP NIO and HTTP APR connectors. sendfile is used automatically for content served via the DefaultServlet and deployed web applications may use it directly via setting request attributes. These request attributes were not validated. When running under a security manager, this lack of validation allowed a malicious web application to do one or more of the following that would normally be prevented by a security manager:

        return files to users that the security manager should make inaccessible
        terminate (via a crash) the JVM

    Additionally, these vulnerabilities only occur when all of the following are true:

        untrusted web applications are being used
        the SecurityManager is used to limit the untrusted web applications
        the HTTP NIO or HTTP APR connector is used
        sendfile is enabled for the connector (this is the default)

    This was fixed in revision 1146703.

    This was identified by the Tomcat security team on 7 July 2011 and made public on 13 July 2011.

    Affects: 6.0.0-6.0.32

    Important: Information disclosure CVE-2011-2729

    Due to a bug in the capabilities code, jsvc (the service wrapper for Linux that is part of the Commons Daemon project) does not drop capabilities allowing the application to access files and directories owned by superuser. This vulnerability only occurs when all of the following are true:

        Tomcat is running on a Linux operating system
        jsvc was compiled with libcap
        -user parameter is used

    Affected Tomcat versions shipped with source files for jsvc that included this vulnerability.

    This was fixed in revision 1153824.

    This was identified by Wilfried Weissmann on 20 July 2011 and made public on 12 August 2011.

    Affects: 6.0.30-6.0.32


Fixed in Apache Tomcat 6.0.32	released 03 Feb 2011

    Note: The issue below was fixed in Apache Tomcat 6.0.31 but the release vote for the 6.0.31 release candidate did not pass. Therefore, although users must download 6.0.32 to obtain a version that includes a fix for this issue, version 6.0.31 is not included in the list of affected versions.

    Important: Remote Denial Of Service CVE-2011-0534

    The NIO connector expands its buffer endlessly during request line processing. That behaviour can be used for a denial of service attack using a carefully crafted request.

    This was fixed in revision 1066313.

    This was identified by the Tomcat security team on 27 Jan 2011 and made public on 5 Feb 2011.

    Affects: 6.0.0-6.0.30


Fixed in Apache Tomcat 6.0.30	released 13 Jan 2011

    Low: Cross-site scripting CVE-2011-0013

    The HTML Manager interface displayed web application provided data, such as display names, without filtering. A malicious web application could trigger script execution by an administrative user when viewing the manager pages.

    This was fixed in revision 1057270.

    This was identified by the Tomcat security team on 12 Nov 2010 and made public on 5 Feb 2011.

    Affects: 6.0.0-6.0.29

    Moderate: Cross-site scripting CVE-2010-4172

    The Manager application used the user provided parameters sort and orderBy directly without filtering thereby permitting cross-site scripting.

    This was fixed in revision 1037779.

    This was first reported to the Tomcat security team on 15 Nov 2010 and made public on 22 Nov 2010.

    Affects: 6.0.12-6.0.29

    Low: SecurityManager file permission bypass CVE-2010-3718

    When running under a SecurityManager, access to the file system is limited but web applications are granted read/write permissions to the work directory. This directory is used for a variety of temporary files such as the intermediate files generated when compiling JSPs to Servlets. The location of the work directory is specified by a ServletContect attribute that is meant to be read-only to web applications. However, due to a coding error, the read-only setting was not applied. Therefore, a malicious web application may modify the attribute before Tomcat applies the file permissions. This can be used to grant read/write permissions to any area on the file system which a malicious web application may then take advantage of. This vulnerability is only applicable when hosting web applications from untrusted sources such as shared hosting environments.

    This was fixed in revision 1022560.

    This was discovered by the Tomcat security team on 12 Oct 2010 and made public on 5 Feb 2011.

    Affects: 6.0.0-6.0.29


Fixed in Apache Tomcat 6.0.28	released 9 Jul 2010

    Important: Remote Denial Of Service and Information Disclosure Vulnerability CVE-2010-2227

    Several flaws in the handling of the 'Transfer-Encoding' header were found that prevented the recycling of a buffer. A remote attacker could trigger this flaw which would cause subsequent requests to fail and/or information to leak between requests. This flaw is mitigated if Tomcat is behind a reverse proxy (such as Apache httpd 2.2) as the proxy should reject the invalid transfer encoding header.

    This was fixed in revision 958977.

    This was first reported to the Tomcat security team on 14 Jun 2010 and made public on 9 Jul 2010.

    Affects: 6.0.0-6.0.27

    Note: The issue below was fixed in Apache Tomcat 6.0.27 but the release vote for the 6.0.27 release candidate did not pass. Therefore, although users must download 6.0.28 to obtain a version that includes a fix for this issue, version 6.0.27 is not included in the list of affected versions.

    Low: Information disclosure in authentication headers CVE-2010-1157

    The WWW-Authenticate HTTP header for BASIC and DIGEST authentication includes a realm name. If a  element is specified for the application in web.xml it will be used. However, a  is not specified then Tomcat will generate realm name using the code snippet request.getServerName() + ":" + request.getServerPort(). In some circumstances this can expose the local host name or IP address of the machine running Tomcat.

    This was fixed in revision 936540.

    This was first reported to the Tomcat security team on 31 Dec 2009 and made public on 21 Apr 2010.

    Affects: 6.0.0-6.0.26

Das alles wirkt sehr unsicher und steht für mich exemplarisch für den gelebten Datenschutzwillen des Staates. Die Daten werden verkauft und es ist kaum jemandem bekannt. Die technische Umsetzung lässt sehr zu Wünschen übrig und läuft über technische Systeme, die bekanntermaßen fehlerhaft sind und dringend aktualisiert werden müssten. Auch scheint eine Endkontrolle und qualifizierte Abnahme bei IT-Projekten (die bekanntermaßen für den Staat meistens recht teuer sind) nicht immer stattzufinden.

Als einzigen Pluspunkt kann ich vermerken, dass es kein zentrales bundesweites Portal mit Online-Fernabfrage für alle Meldedaten zu geben scheint. Dann wären wir sicherlich nicht mehr weit entfernt von dem, was den Israelis vor Kurzem geschehen ist.

Ich bin froh, dass ich mich ausgetragen habe, aber ob jemand mit etwas krimineller Energie und technischem Verständnis nicht trotzdem (kostenlos) an meine Daten (und alle anderen) kommen könnte, halte ich zumindest für fragwürdig. Auf den ersten Blick wirkt das Düsseldorfer System nicht abgehärtet gegen Angriffe.