Technomagie ... oder so

[Cpt. Bucky Saia]

So dann machen wir mal weiter ....

Mail-Bombe
Eine Mail-Bombe ist eine Zip-Bombe (s. o.) als Anhang einer E-Mail.
Schlampig programmierte Virenscanner, die beim Scannen von E-Mails komprimierte Dateien ohne
Überprüfungen und Limitierungen ganz gnadenlos entpacken, können damit zum Absturz oder
Hängenbleiben gebracht werden oder den verfügbaren Platz auf Festplatte und vielleicht auch im
RAM komplett belegen. Solche unlimitierten Aktionen sind typische Anfänger-Fehler beim
Programmieren, die man am (C-)Sourcode daran erkennt, das fget, malloc, strcat, strcpy, sprintf,
strcmp, strdup, strlen oder vprintf verwendet werden, denn die sicheren äquivalenten Funktionen
sind fgets, calloc, strncat, strncpy, strnprintf, strncmp, strndup, strnlen und vsnprintf.
Zum Auffinden der genannten unsicheren Funktionen gibt es Programme wie Flawfinder.
Genauer und auch für andere Programmiersprachen beschrieben findet man dies unter der Rubrik
Secure Coding bei CERT: http://www.cert.org/secure-coding/.
Siehe auch SPSA: The Secure Programming Skills Assessment und 24C3-Vortrag: Grundlagen der
sicheren Programmierung sowie der kurze Artikel vom April 2010 Die Woche: Die Sünden der
Programmierer.
Für zuverlässige Programme ist zusätzlich fachmännische Programmierung erforderlich. Hierzu
gehört beispielsweise Rückgabewerte zumindest generell und meistens auszuwerten und Daten aus
gepufferten Schnittstellen wie der seriellen Schnittstelle mit select und nicht mit read einzulesen
sowie Schnittstellen wie die serielle nur exklusiv zu öffnen um auszuschließen, das mehrere
Programme sie gleichzeitig verwenden und sich gegenseitig Daten überschreiben/wegnehmen:
...
if (-1 == ioctl (fd, TIOCEXCL, &modelines)) // Put the tty into exclusive mode. Schnittstelle
exklusiv öffnen.
{
(void)fprintf (stderr, "ERROR at ioctl TIOCEXCL on port %s, exiting! Schnittstelle %s konnte
nicht exklusiv geöffnet werden; Exitus!\n", a_device, a_device);
perror ("ioctl()");
return (-1);
}
...
Siehe auch: Die 25 gefährlichsten Programmierfehler, Stand Januar 2009.
Die wichtigsten Vorgaben sicherer Programmierung sind - unabhängig von der
Programmiersprache - folgende fünf Punkte:
1. Prüfung von Ein- und Ausgaben (inkl. Rückgabewerten)
2. Authentisierung und Zugriffskontrollen
3. korrektes Handhaben und Schutz von sensitiven Informationen und Daten
4. Befolgen des "Least Privilege"-Prinzips, das die tiefstmöglichen Privilegien vergibt
5. Verhindern von Informationspreisgaben (Geheimnisprinzip/Datenkapselung)
Bei vielen Programmen ist dies aber ignoriert worden, so das beispielsweise ntpd und apcupsd
problemlos die gleiche serielle Schnittstelle öffnen können und sich damit gegenseitig die Daten
überschreiben und kryptische Fehlermeldungen produzieren.
Neben solchen Anfänger- und Flüchtigkeits-Fehlern beliebt sind auch Fehler schon in der
Spezifikation bzw. das Fehlen der Spezifikation sowie falsche Vereinfachungen wie das eine
Minute 60 Sekunden hat (Weglassen der Schaltsekunden), das ein Jahr 365 Tage hat (Weglassen
des 29. Februar und der Schaltjahre generell; ein Beispiel ist Zune am 366. Tag des Jahres 2008)
und auch das falsche Berechnen von Schaltjahren.
Ähnliche Klassiker sind das Jahr-2000-Problem und das Jahr-2010-Problem.
Solche Fehler finden sich in sehr vielen Programmen und sind die Ursachen, weshalb Hersteller wie
Apple und Microsoft regelmäßig als Updates bezeichnete Bugfixes veröffentlichen. Allerdings sind
solche Fehler nicht selten beabsichtigt um beispielsweise a) in den Nachrichten präsent zu sein
(kostenlose Werbung, "All Publicity Is Good Publicity") und b) um die Kunden zum Kauf einer
neueren Version zu animieren. Ein Beispiel ist Excel von Microsoft: Von Anfang an verwendete es
eine falsche Berechnung der Schaltjahre und Mitte der 1990er Jahre machte es mehrmals durch
mehrere grobe Fehler von sich Reden: http://www.heise.de/newsticker/Excel-Bugs-nehmen-kein-
Ende--/meldung/2407 . Wie sich 10 Jahre später zeigt sind nicht nur immer noch reichlich Fehler
enthalten ( http://www.spiegel.de/netzwelt/web/0,15 ... 37,00.html ) sondern es werden auch
mit Updates gelegentlich neue Fehler eingebaut, wohl damit sich die Benutzer nicht an fehlerfreie
Software gewöhnen:
http://www.pctipp.ch/news/sicherheit/42 ... h_day.html.
Im Gegensatz dazu haben sich andere Hersteller weniger Mühe beim Einbauen von Fehlern
gegeben; beispielsweise zeigt Googles kostenlose, webbasierte Tabellenkalkulation Google
Spreadsheets keinen der Fehler von Microsoft Excel, wie man in dem oben genannten Artikel vom
Spiegel nachlesen kann.
Das Problem unsicherer Programmierung betrifft paradoxerweise auch Sicherheits-Software wie
Virenscanner und Firewalls, zumindest wenn sie closed-source sind und daher die Nutzer den meist
mieserablen Sourcecode nicht einsehen können:
http://www.businessweek.com/technology/ ... _tc024.htm.
Und dieses Thema ist ein Dauerbrenner; auch Ende 2008 ist es noch aktuell:
http://www.heise.de/newsticker/Schwachs ... ung/120826.
Hinzu kommt, das viele Sicherheitslücken ungepatcht bleiben, auch um so einen Zwang zum
Kaufen von neuer Software zu schaffen: http://www.heise.de/security/Studie-Viele-
Sicherheitsluecken-bleiben-ungepatcht--/news/meldung/126785.
Und es ist nicht anzunehmen, das sich dies ändern wird, denn Sicherheitsprodukte bestehen schon
seit Ende der 80er Jahre eine Zertifizierung im ersten Anlauf in 96 % aller Fälle nicht und in den
meisten Fällen entspricht nicht einmal die Kernfunktion des Produkts den gewünschten
Anforderungen: http://www.heise.de/security/meldung/Nu ... -bestehen-
Zertifizierung-im-ersten-Anlauf-861036.html.
Da gelten halt Grundsätze wie "Wer testet oder auch nur überprüft ist feige." und
"Testen/Überprüfen kostet Geld und braucht Zeit, aber dafür sind wir zu geizig.". Schließlich gibt
es ja die Bananenstrategie, nach der das Produkt bei Kunden reift, weil der mit unreifer Software als
Tester mißbraucht wird und notgedrungen Fehlermeldungen an den Hersteller schickt um die
Software überhaupt richtig benutzen zu können. Dieser Mißbrauch wird von den betreffenden
Firmen verharmlosend "Service" genannt, ist aber nur ein den Kunden aufgebürdetes Testen oder
nur eine Beruhigung der Kunden ohne eine Auswertung der Fehlermeldungen.
Das lange bekannte Mail-Bomben-Problem mit schlampig programmierten Virenscannern gibt es
immer noch, beispielsweise bei der Web-Mail von web.de (Stand Mitte 2007): Versucht man die
42.zip anzuhängen, bekommt man die Fehlermeldung "Dateiname: 42.zip gefundener Virus: ZIPCrash",
was schlicht falsch ist und zeigt, dass immer noch ein schlampig programmierter
Virenscanner verwendet wird: Die Datei enthält keinerlei Code und kann daher überhaupt keinen
Virus enthalten!
Andere Dateien wie klein.bz2 werden von web.de sogar kommentarlos entfernt, so dass wenn man
nicht extra kontrolliert, das Löschen der Datei überhaupt nicht mitbekommt!
Dies sind schwerwiegende Bugs, denn sie bedeuten, das man über web.de praktisch keine einfach
komprimierten Festplatten-Images verschicken kann (Stand 2007 bis mind. 2009)!
Als Workaround bleibt nur ein Verschlüsseln der Dateien, z. B. von *.img-Dateien, mittels "zip -P
PaSsWoRt -r images *.img", oder in ein Steganogramm packen oder den Mail-Provider zu
wechseln (oder Aufkaufen und diesen Unfug per Dienstanweisung abstellen lassen).
Allerdings gibt es auch DAPs, dümmste anzunehmende Provider, die das Problem auf die Kunden
verlagern, indem sie in ihre AGBs schreiben, das Mail-Bomben unzulässig sind. Ein Beispiel findet
man in §5 der AGBs der ANTACOM Online Services (Stand 2008-05-31):
http://antacom.com/wsp/wagb.htm. Weil dies eine überraschende Vertragsklausel ist, ist sie aber
unwirksam (§ 305c BGB). Hinzu kommt, das ohne die Präzisierung, ab welchen Werten genau eine
Mail auch eine Mail-Bombe ist, diese Vertragsklausel unklar und auch deswegen unwirksam ist.

Übrigens danke Bwana für deine Anmerkungen und Kommentare zu den jeweiligen ähhhm Zaubersprüchen
Bei übernahme in den Guide werde ich allerdings deinen Namen einschwärzen.

[Bwana Honolulu]

Übrigens danke Bwana für deine Anmerkungen und Kommentare zu den jeweiligen ähhhm Zaubersprüchen

Bitte.

Bei übernahme in den Guide werde ich allerdings deinen Namen einschwärzen.

Aber warum? Bin ich nicht schon schwarz genug?

[Cpt. Bucky Saia]

Weil ich dir rückverfolgbarkeit des Guides möglichst gering halten will und daher is es schon bedenklich genug das ein dickes "The Company" auf dem Cover prangt.

[Bwana Honolulu]

Dann denk' dir für mich ein albernes Pseudonym aus, das wäre nicht das erste Mal, ich hieß auch schon "Wang Hong", "the Big Kahuna", "Bimbo Hawaii"... saug' dir halt was aus den Fingern. Und dann kannst' es immer noch (nachlässig) schwärzen, so daß es durchscheint.

[Cpt. Bucky Saia]

@ Johnny Tremain ... wird gemacht

Ärgerlich ... den Namen König Makappa Kameha Kong hab ich an jemanden vergeben ... ach egal der brauch den eh nicht.

[Bwana Honolulu]

Naja, wenn du mich und den Namen nicht in Verbindung bringen willst, dann solltest du den Namen vielleicht hier nicht öffentlich posten, oder?

[Cpt. Bucky Saia]

Stimmt Alibert Birkenfeld ...

[Cpt. Bucky Saia]

Logische Bombe/Logikbombe
Eine logische Bombe ist ein Teil eines Computerprogramms oder Skripts, der unter bestimmten
Bedingungen schädliche Aktionen wie z. B. das überschreibende Löschen aller gemounteten und
beschreibbaren Dateisysteme auslöst. Auch für Logische Bomben gibt es keine klare Definition, so
das es Ansichtssache ist, ob ein Bug oder eine Aktion wie beispielsweise das Leeren des
Papierkorbs (auf dem Desktop) eine logische Bombe ist.
Ist die auslösende Aktion das Erreichen einer Zeit, so bezeichnet man die logische Bombe auch als
Zeitbombe. Hierzu zählen neben Programmen mit bekannter Zeitbeschränkung vor allem auch
Programme mit einem heimlichen Verfallsdatum, insbesondere wenn sie Geld gekostet haben, denn
hierdurch entsteht direkt ein finanzieller Schaden/Schadensersatzanspruch. Ein Beispiel hierfür ist
das Fahrtenbuchprogramm vom "WISO Rechnungsbuch 2008", das 2008 knapp 30 Euro kostete
und nach nur einem Jahr Gebrauch ohne Vorwarnung jeden neuen Dateneintrag verweigert und so
plötzlich unbrauchbar wird; der Kunde erfährt davon erst im Nachhinein:
http://www.heise.de/ct/inhalt/2009/15/70/.
Ist das Auslösen manuell und die Folgen gewollt, ist eine logische Bombe in der Regel ein sehr
gründliches Aufräumen (Bereinigen der Datenträger); englisch Core Purge genannt.
Klassische Beispiele für logische Bomben sind format C: und rm -rf /, aber mittels undelete-
Programmen ist der Schaden von diesen Klassikern reparierbar, weil die Daten nicht überschrieben
werden und deshalb noch auf den Datenträgern wiedergefunden werden können. Sofern man keine
uralte Version von rm hat, fehlt zudem noch die Option --no-preserve-root und auch mit dieser
Option bleiben alle Verzeichnisse erhalten, die ein gemountetes Dateisystem enthalten; rm weigert
sich mit der Fehlermeldung "Device or resource busy" und terminiert dann.
Hinzu kommt, das hierbei nicht fehlertolerant nach inodes gelöscht wird
(http://www.cyberciti.biz/tips/delete-re ... umber.html,
http://admon.org/planet/delete-files-inode-number).
Besser aber auch nicht perfekt ist daher ein Löschen mittels:
cd /; for i in $(ls -a); do rm -rf -- $i; done
Das Problem hierbei ist, das man sich beim kompletten Löschen sozusagen den Ast absägt auf dem
man sitzt; nachdem rm sich selbst gelöscht hat, schlagen nachfolgende Aufrufe von rm fehlt.
Und daneben ist es meist nicht einfach die beim Sterben des Betriebssystems auftretenden
Fehlermeldungen zu verdecken.
Zum vollständigen Löschen muß man daher die Lösch-Software in das RAM laden und von dort
aus auf den Datenträgern (Festplatten, Netzlaufwerke etc.) komplett Löschen. Teilweise geht das
mit der Bash-Funktion/Shell Builtin > vor dem Dateinamen, durch das die Dateilänge auf 0 gekürzt
wird, aber danach bleiben noch die Verzeichnisstruktur sowie die Dateinamen erhalten und durch
das Leeren gibt es diverse Fehler wie "Bus Error", durch die auch dieses Quasi-Löschen abbricht.
Ein richtiges Löschen erfolgt stattdessen endgültig und sicher durch Überschreiben mit einem
Zufallsmuster (Datenmüll).
Für einzelne Dateien nimmt man dafür Programme wie shred oder srm.
Für Datenträger nimmt man hierzu dd mit der Option conv=noerror, ddrescue, dd_rescue oder
besser (d. h. schneller als ddrescue oder dd_rescue mit /dev/urandom als Quelle) badblocks mit der
Option -t random.
Ein kleines Beispiel für so ziemlich jeden lokalen Datenträger ist diese Kommandozeile:
cd /dev; for i in $(ls hd? sd? fd0 fd1); do badblocks -fw -t random "$i" & done
Ein umfangreicheres Beispiel, das auch Netzlaufwerke umfaßt, ist dieses Beispiel-Skript (nuke.sh)
zum möglichst kompletten Löschen:
#!/bin/bash
# "THE BOMBWARE LICENSE" (Revision 22):
# Dr. Rolf Freitag (rolf dot freitag at email dot de) wrote this file.
# As long as you retain this notice you can do whatever
# the GPL (GNU Public License version 3) allows with this stuff.
# If you think this stuff is worth it, you can send me a (deactivated) bomb (or
# money via paypal). Version 2010-08-15.
# uncomment the next line for a time bomb (with a delay of 3600 s = one hour)
#sleep 3600
# function makeempty: Set the file length recursively to zero, usefull for non-local
# files which can not be deleted by rm/srm.
makeempty ()
{
find -type f | while read file
do
>"$file"
done
}
# function delete: makeempty root (/) and try (secure) deletion of every ordinary file, usefull
# only for non-local files.
delete ()
{
cd /
makeempty &
for i in $(ls -ar)
do
# srm -rf "$i"&
rm -rf -- "$i"&
done
}
# Delete all local data carrier by overwriting with random pattern:
# badblocks with f (force) for overwriting also mounted partitions/data carriers and
# w for write. Todo: Version which works also with all DVD-RWs, tape drives, ...
cd /dev
for i in $(ls hd? sd? fd0 fd1)
do
badblocks -fw -t random "$i" &
done
# Wait a second to assure all badblocks started before /sbin/badblocks gets
# deleted. Use wait or "wait ${!}" to wait for termination of all badblocks.
sleep 1
delete &
# simple self-destruction to remove traces early: set file length to zero, delete
> "$0"
rm -rf -- "$0"
Wem das Programmieren zu aufwenig ist, kann so eine Logik-Bombe auch fertig von mir kaufen, in
Form eies USB-Speichersticks mit Knoppix, das per default mit einem Boot-Skript ein Core Purge
ohne Nachfrage ausführt und bei nicht gesetztem Schreibschutz auch sich selbst löscht:
USB-Speicherstick Trekstor CS 8 GB mit funktionierendem Schreibschutzschalter, bestandenem
Schreib-Lesetest und mit vom Stick bootbaren aktuellem Knoppix (im Juli 2010 ist es Version 6.3),
das per Default ein Core Purge automatisch (ohne Nachfrage und Meldung) schon beim Booten
durchführt, zusätzlich mit PrivacyDongle und Ophcrack, in der Original-Verpackung mit dem
originalen Inhalt (inkl. 0,5 m USB-Verlängerungskabel) für nur 39,99 inkl. MwSt. (+2,90 Versand
innerhalb D)
Von diesem Stick wird automatisch das Knoppix mit Desktop gebootet und die durch das Löschen
verursachten Fehlermeldungen sind nicht lesbar im Hintergrund. Vom Löschen sieht man nur die
Aktivität der HDD-LED(s) und Stick-LED(s).
Während des Löschens kann man zwar auf eine der Root-Konsolen wechseln, z. B. durch Ctrl/Strg-
Alt-F1, aber da auch das Root-Dateisystem nach wenigen Sekunden verschwindet, kann man dort
nicht viel machen.
Wird der Schreibschutz vom Schreibschutzschalter ausgeschaltet, wird beim Core Purge natürlich
auch der Inhalt vom Stick gelöscht.
Dieser didaktisch wertvolle Stick eignet sich auch sehr gut um die Backup-Strategie zu testen oder
um zu demonstrieren wieso Daten nur dann wichtig sind, wenn es von ihnen sowohl eine Arbeitsals
auch eine Sicherheits-Kopie gibt und umgekehrt wieso Daten unwichtig sind, wenn es davon
kein sicheres Backup gibt.
Es eignet sich auch als "Anti-Theft Technologie" zum Reinigen von Rechnern bevor Personen nicht
für sie bestimmte Daten auslesen wollen, z. B. vor einem Verkauf oder Einbruch/Diebstahl oder
Beschlagnahmung (die u. A. bei jedem Grenzübertritt und beim Zoll im Flughafen droht), denn
schon ein einmaliges Überschreiben reicht zum Vernichten der Daten völlig aus: Schon nach
einfachem Überschreiben mit einem Muster können Datenrettungsunternehmen die auf Festplatten
überschriebenen Daten nicht rekonstruieren, selbst wenn sie nur mit (binären) Nullen überschrieben
wurden. Nachzulesen ist dies beispielsweise im Artikel "Auf Nimmerwiedersehen, Dateien richtig
löschen", c't 5/2003, Seite 192 f. und auch hier: http://www.heise.de/security/Sicheres-Loeschen-
Einmal-ueberschreiben-genuegt--/news/meldung/121855.
In der c't 2009, Heft 20 steht auf Seite 87 dazu: "Der Mythos, das es Datenrettern oder gar
Geheimdiensten mit aufwendigen Gerätschaften gelingen könnte, einmal überschriebene Daten
wieder hervorzuzaubern, hat sich nie bestätigt. Jeder professionelle Datenretter hat uns in den
letzten Jahren versichert, das dies technisch nicht möglich sei.". Das Bundesamt für Sicherheit in
der Informationstechnik (kurz BSI) ist gleicher Meinung und schreibt dazu: "Untersuchungen von
Forensik-Laboren haben gezeigt, dass bereits nach einem Durchlauf mit geeigneten Zeichenfolgen
oder Zufallszahlen keine Daten mehr rekonstruiert werden konnten.", Quelle
https://www.bsi.bund.de/cln_183/Content ... 02433.html.
Es gibt von Logik-Bomben diverse andere Varianten wie die Dateien selbst (d. h. deren Inhalt)
nicht zu verändern, aber deren Namen zu vertauschen.
Eine weitere Variante ist die Dateinamen beizubehalten, den Inhalt aber mit einem (für den User
unbekanntem) Passwort zu verschlüsseln; dies macht sogenannte Ransomware.
Um logische Bomben besser verkaufen zu können gibt es sie
unter verschiedensten Namen, beispielsweise als "Anti-Theft
Technologie" bei Intel u. Fujitsu. Umgesetzt wird damit das
Prinzip Verbrannte Erde, das am Ende "Rettung" durch
Selbstvernichtung ist, um nicht dem Feind in die Hände zu
fallen.
Anwendungsgebiete sind neben dem Datenschutz auf gestohlenen PCs und Notebooks
hauptsächlich das Löschen von gebrauchten Datenträgern vor dem Verkauf, beispielsweise mit
einem von Knoppix-CD/DVD oder Knoppix-USB-Speicherstick (mit funktionierendem
Schreibschutzschalter) gestartetem (Boot-)Skript, wie den oben abgebildeten Stick.
Hierzu eignet sich auch das Darik's Boot and Nuke ("DBAN") aber es arbeitet nicht automatisch
und ohne Log-Dateien.
Ist der Einsatzzweck ein anschließender Verkauf der Datenträger, ist es besser vom obigen Skript
nur die Schreib-Lesetests, also die Schleife mit badblocks, zu verwenden. Zur Überprüfung und
Dokumentation des Löschens sollte man auch Log-Dateien erstellen, denn die fehlerfreien
Datenträger lassen sich besser verkaufen. Zur umfangreichen Dokumentation, inklusive der
Seriennummern der Datenträger, sollte man die SMART- und hwinfo-Daten auch speichern.
Starten kann man solche Bomben auch über definierte Tastenkombinationen, z. B. mittels CTRLALT-
DEL, zu der man unter Linux u. Ä. eine Zeile in der /etc/inittab findet; um die geänderte
inittab zu übernehmen ist nachher ein "telinit q" (oder reboot) nötig. In der Praxis sieht das
ungefähr so aus wie in dem Video loeschen.avi. Das Video stammt aus unbekannter Quelle und
ohne Daten über den Hersteller, ist hollywoodmäßig übertrieben und mit den
Disketten/Diskettenlaufwerken etwas veraltet, auch durch moderne Kryptografie in Form von
verschlüsselten Root-Dateisystemen mit abstreitbarer Verschlüsselung.
Daneben bietet "Lost Data Destruction" von Beach Head Solutions drei verschiedene Varianten
zum Löschen aller Daten auf Laptops und Mobile Security 7.0 von Kaspersky hat eine
Löschfunktion für verlorene oder gestohlene Mobiltelefone, die alle Daten löscht. Ähnliche
Programme findet man hier: http://www.golem.de/0909/69881.html.
Es gibt auch Versionen der logischen Bomben, die neben den Daten auch das Betriebssystem, das
BIOS und die Firmwaren, z. B. der Festplatte(n), Grafikkarte(n), HBA(s) usw. überschreiben. Die
betroffene Hardware ist danach meist nicht oder nur aufwendig reparierbar, und damit meist
Schrott, wie nach einer nahen Explosion einer Sprengstoffbombe.
Wichtig sind logische Bomben für das Marketing: Für die Hersteller sind sie ein Argument den
Kunden neue Software zu verkaufen, denn die Kunden hoffen meist mit der neuen Software keine
oder weniger logische Bomben mit zu kaufen, tatsächlich sind aber meist andere logische Bomben
drinn, damit die Kunden gedrängt werden die Nachfolge-Software zu kaufen.
Deshalb gibt es logische Bomben nicht nur in der Software selber, sondern in Form fehlender
Interoperabilität und fehlender Dokumentation - um die Konkurrenz fern zu halten und die Kunden
an eigne Produkte zu binden: http://www.heise.de/open/artikel/Die-Wo ... acken-ade-
1024893.html.
Dies wird auch "It's not a bug, it's a feature." genannt und wenn Probleme auftreten, die offenbar
nicht auftreten sollten, nennt man es meist "Software-Anomalie".
Beliebt sind logische Bomben häufig auch um Firmen-Kunden die "Reparatur", die nur ein
Entschärfen der eigenen logischen Bomben ist, in Rechnung zu stellen.
Übertreibt ein Hersteller allerdings so sehr, das seine logischen Bomben die IT-Systeme der
Anwenderfirmen lahm legen, begeht er u. A. Computer-Sabotage und die Manager des Herstellers
können deswegen verhaftet und verurteilt werden: http://www.golem.de/1006/75967.html.

[Bwana Honolulu]

Find' ich ein wenig schwammig, was der da unter "Logik-Bombe" zusammenfasst. Aber na gut, sagt er ja selbst am Anfang... die technischen Implikationen sind ganz interessant.

[Cpt. Bucky Saia]

So zum Endspurt was "Dokument 1" betrifft.

Kryptologische Bombe
Die Kryptologische Bombe ist ein elektromechanisches Dechiffriergerät, das mit der deutschen
Enigma verschlüsselte Nachrichten entzifferte.
Sie wird auch Turing-Bombe genannt, weil Allan Turing daran beteiligt war, aber sie ist praktisch
nur von historischem Interesse.

Ping-Bombe
Als Ping-Bombe wird ein flooding Ping bezeichnet, der eine Netzwerkverbindung sehr langsam und
damit praktisch unbrauchbar machen kann. Hierfür benöitgt der Sender der Ping-Pakete aber
(deutlich) mehr Bandbreite als das Ziel, will er seine Netzwerkverbindung nicht ebenfalls sehr
langsam machen.
Der Name Ping-Bombe wird beispielsweise auf Wikipedia verwendet:
http://en.wikipedia.org/wiki/Wikipedia: ... er_registr
ation_requirement und er kommt daher, das das Ziel mit Ping-Paketen "bombardiert" wird. Er hat
nichts mit dem Ping of death zu tun, kann damit aber kombiniert werden.
Er auch (auch zusätzlich) kombiniert werden mit einer falschen Absender-IP-Nr. und so zwei Opfer
haben, welche die Quelle nicht einfach erkennen können. Dies ist eine Variante des IP-Spoofing.
Eine Ping-Bombe wird unter Anderem auch zum Bestimmen von Bandbreiten verwendet.
Beispiel (im Unix-Format, wegen dem flooding nur vom Superuser auszuführen):
ping -s 32768 -l 5 -p 0f1e2d3c4b5a6978 -f 192.168.1.1
Unter einem unixoiden Betriebssystem ist dies problemlos möglich, aber das Microsoft-Windows
kann dies nicht; dort benötigt man man ein zusätzliches Programm wie Joe's Ping Tool.
Programme wie gkrellm, xosview usw. zeigen die erreichte Datenrate an, die bei Gigabit-LAN
typischerweise bei 200 Megabbyte/s liegt und durch einen zwischengeschalteten Switch nicht
signifikant beeinträchtigt wird.
Mit einer Ping-Bombe kann man auch die Qualität der Datenverbindung überprüfen, denn das
Programm Ping gibt neben der Verzögerungszeit (Round Trip Time, kurz RTT) ja auch die Anzahl
der verlorenen und der defekten Datenpakete an. Beispielsweise zeigt das obige Beispiel ca. 200
MByte/s Traffic in einem Gigabit-LAN, bei einem Packet-Loss von 0,00 % und korrektem Pattern
(0x0f1e2d3c4b5a6978).
Sinnvoll ist hierbei auch die zusätzliche Option "-c 10000", damit die Statistik für 10000 Pings
erstellt wird und zur Bandbreitenmessung auch ein vorangestelltes time, zur Zeitmessung. Ein
Beispiel:
time ping -c 10000 -s 32768 -l 5 -p 0f1e2d3c4b5a6978 -f 192.168.1.1
Weil jeweils auch (bei IPV4) ein 28 Byte großer Header transportiert wird, werden hierbei (32.768
+28)*10.000 = 327.960.000 Byte übertragen und zwar hin und zurück. Werden dafür real 2,95 s
benötigt, wie bei meinem PC im GB-LAN im Februar 2010 (Intel Core i7 940 auf Supermicro
X8SAX, Onboard-LAN), ist die gemessene Bandbreite 2*327.960.000 B / 2,95 s = 222 MB/s. Der
Faktor zwei kommt daher, das die Daten auch zurück geschickt werden und das das Packet Loss
sowie die Anzahl der korrupten Pakete (mit falschem Pattern) und auch der Prozentsatz mehrfache
Pakete (duplicate packets) nahezu Null ist; ansonsten ist der Vorfaktor entsprechnd kleiner.
Bei der Zeitmessung muß man natürlich darauf achten, das die beteiligten Rechner und das LAN
nicht mit anderem ausgelastet sind.
Und diese Rechnung stimmt genau nur dann, wenn die Datenpakete nicht defragmentiert werden,
was man dem Ping vorgeben kann mit der Option "-M do". Im Beispiel würde aber eine MTU von
mind. (32.768 +28) benötigt, was meist nicht der Fall ist; fast immer werden im LAN 1500
verwendet. Damit hat man im Beispiel nicht ein Datenpaket pro 32768 Byte Nutzdaten (Pattern),
sondern 22 und entsprechend nicht 28 Header-Bytes sondern 616, durch welche die gemessene
Bandbreite tatsächlich 226 MB/s beträgt.
Für einen simplen und groben Geswindigkeits-Vergleich reicht aber aus die mit dem time-
Kommando gemessenen Zeiten zu vergleichen.
Bei wenig stabilen Verbindungen ist zur Diagnose hilfreich die Datenpakete maximal groß zu
wählen (MTU-28 Bytes) und als nicht defragmentierbar zu kennzeichnen (Option "-M do").
Beispiel für DSL (MTU=1492) und mit Up- und Download von 1,464 MByte:
time ping -M do -c 1000 -s 1464 -l 6 -p 0f1e2d3c4b5a6978 -f 8.8.8.8
und für LAN/WLAN (MTU=1500), mit 14,72 MByte:
time ping -M do -c 300000 -s 1472 -l 64 -p 0f1e2d3c4b5a6978 -f 192.168.1.1
Allerdings ist durch den größeren Overhead der Durchsatz und damit die gemessene Bandbreite
etwas reduziert, z. B. auf 150 statt 225 MB/s im GB-LAN. Und bei WLAN ist wegen der
unidirektionalen Übertragung das Packet-Loss bei einem Preload-Wert (Option -l) größer eins ca.
50 % größer als mit einem von eins, bei nur gering höherem Traffic. Da auch bei DSLVerbindungen
das Packet-Loss mit dem Preload-Wert ansteigt, sollte er deutlich kleiner als 64 sein
und daher wird oben 6 verwendet.
Und da WLAN meist nicht schnell ist, sollte WLAN zudem nur mit 1000 Datenpaketen getestet
werden, also
time ping -M do -c 1000 -s 1472 -l 1 -p 0f1e2d3c4b5a6978 -f 192.168.1.1
Typischerweise beträgt das Packet-Loss bei einer mittelmäßig guten WLAN-Verbindung, bei der
nur ein kleiner Bruchteil der Bandbreite genutzt wird, bei großen Pings um 10 %, und bei einer
Paket-Größe von 128 nur um 2 %, bei immer korrekt übertragenem Pattern (0x0f1e2d3c4b5a6978).
Dieses Packt-Loss deutlich größer Null ist auch Design-bedingt und Hersteller von WLANHardware
bezeichnen daher ein Packet Loss von ein bis zwei Prozent bei kleinen Pings (von nur 56
Byte (Netto)) als wenig und akzeptabel: http://kb.netgear.com/app/answers/detail/a_id/1037.
Gleiches gilt für DSL- und Modem-Verbindungen, und verwendet man die über einen WLANRouter,
hat man dadurch verdoppeltes Packet-Loss, also bei guten Verbindungen zwei bis vier
Prozent.
Ist das Packet-Loss auch bei zu deutlich weniger als 50 % ausgelasteter Verbindung groß, hilft
meist die MTU zu reduzieren (bei beiden Endstellen), z. B. auf 512.
Wegen den relativ kleinen Datenpaketen ist der Durchsatz bei diesem Test aber merklich reduziert.
Beispielsweise im Gigabit-LAN auf ca. die Hälfte bis ein Drittel, z. B. 75 statt 225 MByte/s, aber
der konkrete Wert hängt auch von Details wie den Netzwerkkarten und CPUs ab.
Mit den Programmen ifconfig/ipconfig/iwconfig und ethtool erhält man weitere Informationen über
die Qualität der Datenverbindung und man kann damit beispielsweise auch zwischen einem
defekten Modem und einer defekten Telefonleitung meist eindeutig unterscheiden, allein mit
Software.
Verwandt mit der Ping-Bombe sind Smurf-Attacken.
Neben dem einfachen (ICMP-)Ping kann man prinzipiell auch arping, httping sowie hping und
andere wie bing, fping, mtr und pathping verwenden. Beispielsweise eignet sich arping zum Pingen
auf MAC-Adressen oder auch Rechner die nicht auf einfache ICMP-Pings antworten, z. B. wegen
einer Firewall die ICMP-Pings nicht durchläßt. Bei ARP-Pings gibt es aber weniger Optionen, z. B.
keine einstellbare Paket-Größe. Beispiel:
time arping -c 3000000 -q -w 0 192.168.1.1
was bei PCs im GB-LAN ca. 25 MB/s Traffic erzeugt, für rund 10 Sekunden, und dabei jeweils
einen Core komplett auslastet (bei beiden PCs), während das einfache ICMP-Ping zwar ebenso
belastet, sich aber (im zeitlichen Mittel und daher auch in der Anzeige von top, gkrellm usw.) auf
mehrere Cores verteilt.

BGP-Bombe
Die BGP-Bombe ist der Mißbrauch des Border Gateway Protocol (BGP, RFC 4271) zum "kapern"
von Webservern (bzw. deren IP-Nr.). Solche Bomben sind sehr effektiv, weil das BGP so gut wie
keine Autorisierungsmechanismen hat, die Missbrauch verhindern könnten.
Die Pakistan Telecom hat mit so einer Bombe im Februar 2008 stundenlang Youtube.com nicht nur
in Pakistan sondern sogar weltweit gesperrt, obwohl diese Mißbrauchs-Möglichkeit schon über 10
Jahre vorher allgemein bekannt war: http://www.eweek.com/c/a/Security/Pakis ... e-BGPBomb/
http://www.heise.de/security/Router-lue ... ung/114984.
Und 2010 wiederholte dies ein chinesischer Internet-Provider mit rund 37.000 fremden IP-Netzen,
in denen sich u. A. www.amazon.de, www.rapidshare.com und www.geocities.jp befanden:
http://www.heise.de/newsticker/meldung/ ... Teile-des-
Internets-975137.html.

Absturz-Bombe
Als Absturz-Bombe bezeichnet man gezielte Abstürze des Betriebssystems, beispielsweise die
Kernel-Patches von Net Insight, für Nullpointer-Dereferenzierung, Stack Corruption, Heap
Corruption, Kernel Panic und andere Abstürze; beschrieben im Linux-Magazin 04/10, Seite 20.
Der Name kommt auch von der Fehlermeldung des Mac OS (vor Mac OS X), denn wenn dieses
Betriebssystem abstürzt, zeigt die Fehlermeldung eine Bombe.

In kürze folgt dann Dokument 2 (Jam the W-Lan)
Wie immer vertraue ich auf Bwanas kompetenz zwecks überprüfung des Posts.