Moin,
in Kürze: Ich wollte probieren, inwieweit ich unter Windows mit einem
Programm in die Daten eines anderen Programms/Prozesses eingreifen kann.
Dabei stehe ich noch ganz am Anfang: Mein kleiner Versuch: Programm 1
legt eine Zeichenkette in den Speicher und gibt diese im
5-Sekunden-Rhythmus aus, das zweite legt ebenfalls eine Speicherkette in
den Speicher, legt einen Zeiger darauf an und zählt anschließend diesen
Zeiger so weit runter, dass als Ausgabe eigentlich die Zeichenkette des
ersten Programms erscheinen müsste - das ist aber nicht der Fall, obwohl
die Adressen übereinstimmen:
1
//Programm 1
2
#include<stdio.h>
3
#include<windows.h>
4
5
intmain(intargc,char*argv[])
6
{
7
charausgabetext[]="Beispieltext\n";
8
char*zeiger=&ausgabetext[0];
9
printf("Adresse von ausgabetext: %i\n",zeiger);
10
while(1){
11
printf(ausgabetext);
12
Sleep(5000);
13
}
14
return0;
15
}
1
//Programm 2
2
#include<stdio.h>
3
intmain(intargc,char*argv[])
4
{
5
charmeintext[]="MeinText\n";
6
char*zeiger;
7
inti;
8
zeiger=&meintext[0];
9
for(i=0;i<30;i++){
10
printf("%i\t",zeiger);
11
printf("%3i\t%c\n",zeiger[0],zeiger[0]);
12
zeiger=zeiger-1;
13
}
14
return0;
15
}
Ich erhalte als Ausgabe von Programm 1:
Adresse von ausgabetext: 1638202
Beispieltext
[...]
Ausgabe von Programm 2:
1638206 77 M
1638205 43 +
1638204 -35 Ý
1638203 0
1638202 24
1638201 -1 ÿ
1638200 56 8
Das "M" von "MeinText" wird also ausgegeben, aber für Adresse 1638202
kein "B" von "Beispieltext". Mache ich hier einen Denkfehler
(wahrscheinlich)? Oder liegt das nicht am C-Code, sondern an ...?
Hinweis: Ich rufe beides vom Windows7-Kommandozeileninterpreter "cmd"
aus auf; starte nacheinander prog1, prog2.
Danke für jeden Hinweis!
soll das ein April-Scherzt sein?
Wenn nein. Alle aktuellen Betriebssysteme verwenden virtuellen Speicher.
Jede Anwendung hat seinen eignen Privaten Adressraum.
Ja es gibt Möglichkeiten den Speicher von anderen Programme zu ändern,
aber dann muss man das mithilfe der API vom MS machen.
Matthias schrieb:> in Kürze: Ich wollte probieren, inwieweit ich unter Windows mit einem> Programm in die Daten eines anderen Programms/Prozesses eingreifen kann.
Das ist eine der Aufgaben des Betriebssystems, so etwas nicht einfach
mal eben so zuzulassen.
Moin,
ja, genau, das Thema mit "privaten Adressräumen" kenne ich. Und nein,
kein Aprilscherz.
Letzten Endes ist es genau das, was ich bisher nicht verstehe, und
wirklich mal nachvollziehen will: Wie genau kann es durch Pufferüberlauf
und/oder gezieltes Schreiben in den Speicher möglich sein, einen Prozess
mit höheren/mit Administratorrechten zu übernehmen und sich auf diese
Weise eben Administratorrechte zu verschaffen? Klar, in der Umsetzung
der Betriebssystemfunktion für die privaten Adressräume können Fehler
sein. Und auch klar, wenn ich es schaffe, in den Speicherbereich eines
anderen Prozesses zu schreiben, kann ich das Programm/den Prozess
"verwirren" und zum Absturz bringen. Aber dann hätte ich das Ziel,
diesen Prozess bzw. dessen Rechte zu übernehmen, ja wiederum nicht
erreicht...
Gruß,
Matthias
Matthias schrieb:> Wie genau kann es durch Pufferüberlauf> und/oder gezieltes Schreiben in den Speicher möglich sein, einen Prozess> mit höheren/mit Administratorrechten zu übernehmen und sich auf diese> Weise eben Administratorrechte zu verschaffen?
Auf Deutsch, du willst Exploits finden.
Natürlich nur zum akademischen Zweck :-)
Zum Glück ist das nicht ganz so einfach.
Matthias schrieb:> Letzten Endes ist es genau das, was ich bisher nicht verstehe, und> wirklich mal nachvollziehen will: Wie genau kann es durch Pufferüberlauf> und/oder gezieltes Schreiben in den Speicher möglich sein, einen Prozess> mit höheren/mit Administratorrechten zu übernehmen und sich auf diese> Weise eben Administratorrechte zu verschaffen?
kann man das denn?
Wenn ein Programm als root/admin läuft und man schafft es von Außen mit
falschen eingaben einen Pufferüberlauf zu erreichen, kann man damit die
Kontrolle über diesen Prozess übernehmen.
Dafür braucht man aber kein 2.Programm.
Peter II schrieb:> damit müsste es möglich sein, durch eine falsche Eingabe beliebige> Programm zu starten.
wenn du sowas zulässt, brauchts nichtmal einen Pufferüberlauf durch
gets.
Vlad Tepesch schrieb:> Peter II schrieb:>> damit müsste es möglich sein, durch eine falsche Eingabe beliebige>> Programm zu starten.>> wenn du sowas zulässt, brauchts nichtmal einen Pufferüberlauf.
wie meinst du das? Es sollte ja "offiziell" nur "dir" gestartet werden.
Matthias schrieb:> Weise eben Administratorrechte zu verschaffen? Klar, in der Umsetzung> der Betriebssystemfunktion für die privaten Adressräume können Fehler> sein.
Du stellst dir das ein wenig zu einfach vor.
Das ist nicht einfach nur eine Software Sache, sondern da ist auch
Hardware im Spiel. Da gibt es eine MMU (Memory Management Unit), die die
Adressumsetzung anhand von Tabellen macht. In der Tabelle ist
festgehalten, welche virtuelle Adresse auf welche physikalische Adresse
im tatsächlichen RAM führt. Dies geschieht in Form von Speicherblöcken.
Wenn dein Programm startet, dann wird vom Betriebssystem eine Belegung
in die MMU geschrieben, die deinem Programm vorgaukelt völlig alleine im
Speicher zu sein. Im Rahmen der dir bereits zugewiesenen Speicherblöcke
kannst du nicht auf die anderer Prozesse zugreifen. Denn entweder dein
Programm greift auf einen regulär dir zugewiesenen Speicherbereich zu,
dann setzt die MMU diesen Zugriff in den deinem Prozess zugewiesenen
Speicherbereich um und du greifst auf den Speicherblock zu, der vom
Betriebssystem für dich reserviert wurde.
Oder aber du greifst mit einer (virtuellen) Adresse auf den Speicher zu,
dessen Block noch nicht für deinen Prozess reserviert wurde. In dem Fall
löst dann die MMU eine Sonderbehandlung aus, das Betriebssystem springt
an und bestimmt einen physikalischen Speicherblock, der dann auf genau
diese von dir benutzte Adresse führt und trägt den zusätzlich in die MMU
für dich ein. Ab sofort gehört dieser Speicherblock dann zu deinem
Prozess (und ist natürlich vorher vom Betriebssystem für dich
freigeschaufelt worden, wenn er schon anderweitig benutzt war)
Um also an der MMU vorbei in den Speicher zu adressieren, musst du dich
an der MMU vorbeischummeln, was aber so nicht geht, weil deine
Berechtigung nicht ausreicht um die MMU zu manipulieren.
Wie bereits erwähnt: Bei Multitasking Systemen ist es eine der
wichtigeren Aufgaben des Beteriebssystems (und der Hardware), die
einzelnen Tasks so voneinander zu trennen, dass es zu keiner wie auch
immer gearteten unfreiwilligen gegenseitigen Beeinflussung kommt.
Insbesondere darf ein Amok laufender Task nicht einfach so einen anderen
Task beeinflussen in dem er einfach den Speicher niederbügelt.
Hallo Karl-Heinz,
danke für die Erklärungen. Aber im Grunde bin ich damit nicht weiter, da
ich einen "Zirkelbezug" habe: Um mir Administratorrechte durch
Speicherüberschreiben zu verschaffen, brauche ich vorher schon
Adminrechte, um die Adressverwaltung/MMU zu manupulieren.
Wir hatten einfach neulich im Kollegenkreise geplaudert, und irgendwie
meint jeder, Cyberangriffe seien alltäglich, und überhaupt seien 95% der
Privatrechner schon gehackt. Zusätzlich sieht und liest man z.B. bei
heise.de regelmäßig von Pufferüberläufen, die ggf. genutzt werden
können, um ein System zu kompromittieren, weshalb schnellstens Update xy
eingespielt werden sollte.
Ich kann für mich dieses "ggf. genutzt werden können" nicht
quantifizieren bzw. sonst irgendwie fassen (und ich habe auch nicht vor,
wirklich etwas zu hacken o.ä.). Vielmehr habe ich "damals"
Wirtschaftsinformatik studiert, kenne daher "theoretisch" auch die
Betriebssystemkonzepte sowie Programmierung (bin aber berufsmäßig eher
bei "Wirtschaft" gelandet).
Mir fehlt einfach zum Verständnis der letzte Schritt von "ich schreibe
Daten in den Speicherbereich eines anderen Prozesses" zu "ich habe
Adminrechte auf dem System".
Im Grunde muss es wohl wie folgt laufen: Nicht im Datenbereich des
Speichers, sondern im Funktionsaufrufsbereich (Stack) liegen
Rücksprungsadressen. Ein mit Admin-Rechten laufendes Programm hat
seinerseits eine andere Funktion aufgerufen und vorher seine
Rücksprungadresse dort abgelegt. Ich als Angreifer schreibe eine
"bösartige" Funktion (etwa rufe eine Shell auf) und ermittle deren
Adresse und packe sie - nach trial&error - auf den Stack. Wenn jetzt das
Adminprogramm bzw. das davon aufgerufene zurückspringen will, sucht es
sich die Sprungadresse raus, erwischt aber die von mir dort stattdessen
hinterlegte Adresse, springt daher in meine Funktion, und schon habe ich
eine Eingabeaufforderung mit Admin-Rechten.
In diesem theoretischen Vorgang, glaube ich nur, dass bei Manipulation
des Stack es viel eher zu einem Crash des Admin-Programmes kommen wird.
Und außerdem muss ich erst einmal Schreibrechte auf beliebige Stellen
bzgl. des Stack bekommen...
Die Frage ist, läuft es wirklich so ab, oder gibt es noch andere
Möglichkeiten?
Hi
Wenn der angegriffene Prozess (Programm) nicht schon mit Adminrechten
läuft ist das typischerweise ein (mindestens) zweistufiger Vorgang.
Erstmal greift man ein Programm an um eigenen Code zur Ausführung zu
bringen und dann versucht man über eine Fehler im OS höhere Rechte zu
erlangen.
http://de.m.wikipedia.org/wiki/Rechteausweitung
In heutigen Systemen kann das ordentlich komplex werden da sich ein
Angreifer diversen Hürden stellen muss um z.B. per manipulierter
Onlinewerbung an Adminrecht zu kommen.
Matthias
Nur das der Stack auch von der MMU verwaltet wird - da es einfach nur
Speicher ist.
Das ist nichts was man eben mal an 'nem Abend ausprobiert um am
folgenden Abend am Stammtisch darüber nett zu plaudern. Vielmehr geht es
um ein sehr spezielles Thema. Die Tatsache, dass oft recht einfach
aussehende Kommandos und Vorgänge reichen um sich irgendwo rein
zuhacken, verdeckt, dass man diese Kommandos, Funktionen etc. in der
Regel so gar nicht ausführt, weil sie für den normalen Benutzer keinen
Wert hätten. Mal abgesehen von dem Fall, das jemand gezielt nach solchen
Lücken sucht, kommt man eher durch Zufall darauf. Um aber nach den
Lücken zu suchen, braucht man schon ein recht gerütteltes Maß an
Systemkenntnissen, Programmierfähigkeiten und Geduld.
Was Du da mit einfachem herum kopieren oder Stack überschreiben träumst,
dass hat vor 30 Jahren vielleicht mal auf 'nem MP/M-Rechner geklappt.
Seit 29 Jahren geht das da auch nicht mehr so einfach.
Wenn Du da nicht extreme Leidenschaften für entwickelst oder Deinen
Lebensunterhalt mit verdienen willst, lass es einfach. Ehe Du soweit
bist, dass Du da was findest, was aktuell funktioniert, haben Deine
Enkel schon Häuser gebaut. Man muss auch bedenken, dass die Gurus auf
dem Gebiet die Entwicklung von Angriffen und Gegenmassnahmen in der
Regel auch schon seit Jahrzehnten mitmachen.
>Man muss auch bedenken, dass die Gurus auf>dem Gebiet die Entwicklung von Angriffen und Gegenmassnahmen in der>Regel auch schon seit Jahrzehnten mitmachen.
<<< Ein anderer Matthias
Eine sehr einseitige Betrachtung der Materie.
Neben 'Gurus' auf dem Gebiet der IT-Sicherheit, gibt es da draußen
abertausende User, denen etwaiges Know How fehlt.
Jeden Tag wird neue Software auf den Markt geworfen, die die gleichen
Fehler, wie vor 30 Jahren aufweist, man muss sie nur finden.
Und Windows betreffend, ganz ehrlich, Windows ist alles andere, aber
nicht 100 % Exploitgeschützt.
Darüber hinaus, sicher, es gibt Sprachen welche Typsicherheit als Kredo
formulieren, aber nach wie vor kann mit C,...,... programmiert werden.
Es gibt im Prinzip zwei Ansätze:
1) Ein Programm mit Adminrechten verarbeitet Daten (zB per TCP/IP oder
es liest Daten von der Platte) und hat in der Verarbeitung einen Fehler.
Wenn Du diesen Fehler findest und der geeigneter Natur ist, dann kannst
Du mit manipulierten Daten zB den Stack überschreiben. Auf dem Stack
liegen nicht nur die Rücksprungadressen, sondern auch die
Funktionsparameter und die lokalen Variablen.
2) Jedes Programm kann Betriebssystemaufrufe machen und wenn eine
Funktion des Betriebssystems nicht sauber programmiert wurde und seine
Parameter nicht richtig überprüft, dann kannst Du damit ebenfalls
Variablen bzw. den Stack überschreiben. Du bist dann im Betriebssystem
und hast alle Rechte.
Wie das mit dem Stack überschreiben funktioniert wird zB in der
Wikipedia erklärt: http://en.wikipedia.org/wiki/Stack_buffer_overflow
Dort werden auch die von Bitflüsterer erwähnten Gegenmaßnahmen
besprochen.
Prinzipiell geht es dabei um das Finden von Fehlern. Meistens
Programmierfehlern, seltener auch um Konfigurations- oder Designfehler.
Diek schrieb:> Kann man sowas nicht über den shared memory machen?
An den muss man aber erst mal herankommen. Und um auf Speicherbereiche,
die anderen Prozessen gehören, zugreifen zu können, bedarf es
entsprechender Berechtigungen.
Mit Programmiersprachen hat das ganze weniger zu tun.
Matthias schrieb:> Mir fehlt einfach zum Verständnis der letzte Schritt von "ich schreibe> Daten in den Speicherbereich eines anderen Prozesses" zu "ich habe> Adminrechte auf dem System".
Der ganze Sinn von Task-Trennung, Speicherschutz, Rechteverwaltung etc.
ist ja genau, Deine dunklen Absichten zu verhindern.
Wenn es so einfach wäre, sich Adminrechte zu beschaffen, bräuchte man
keine Adminrechte.
Das von Dir beschriebene Szenario funktioniert nur dann, wenn
- das System keinen entsprechenden Schutzmechanismen hat (z.B. das alte
AmigaDOS),
- oder in Programmcode, der mit höheren Rechten läuft, ein Fehler
existiert, der sich ausnutzen läßt. Solange Du nicht explizit so einen
Fehler ausnutzst, kannst Du Dir auch nicht höhere Rechte beschaffen.
Man sieht hier mal wieder wie unvollständig das wissen selbst mehrere
Fachleute sein kann wenn niemand sich damit ernsthaft beschäftigt und
das wir hier eine Hardwareform haben.
Wenn du es nicht explizit deaktivierst wird dir jeder aktuelle Compiler
aus genau deinen Absichten mindestens folgenden Schutzmechanismus
einbinden.
http://de.wikipedia.org/wiki/Address_Space_Layout_Randomization
Damit lässt sich zwar erst mal kein buffer overflow verhindern, jedoch
ist die RAM-aufteilung immer anders. Lesen/Schreiben von fremden
Prozessvariablen so wie du es vor hast funktioniert nur an dynamischen
Adressen.
Das hat mit windows api und mmu erst mal nix zu tun
Meine Empfehlung: such dir eine geeigneteres Forum wenn du dich
ernsthaft damit beschäftigen willst.
Ui, endlich mal was wo ich 'ne Antwort geben kann statt nur fragend blöd
rumzustehen. :)
Buffer overflows (und die zugehörigen Exploits) sind im Prinzip nicht
weiter kompliziert, man sollte allerdings ein wenig Wissen um die
Funktionsweise des x86 (oder irgendeines) Assemblers mitbringen. Da ich
jetzt nicht weiss wie die geneigten Boardmods drauf reagieren wenn ich
hier "Hacking 101" abspule, belass ich's besser beim theoretischen Teil.
Wobei ich dazu sagen will dass "einfach mal eben" Buffer-Overflow nutzen
ohnehin spätestens mit Windows Vista und ASLR nicht mehr "einfach so"
funktioniert.
Was es braucht damit das funktioniert ist ein Programm, das eine
Schwachstelle hat, und zwar eine sehr besondere. Das Programm muss
Userdaten verarbeiten (also irgendwelchen Input, der Klassiker beim
Buffer Overflow sind Strukturen die entweder variable Länge haben können
oder wo das System dämlicherweise die Länge der Struktur sich vom
Benutzer vorgeben läßt). Zusätzlich muss das Programm diese Daten auf
dem Stack speichern. Wird hier nun nicht hinreichend geprüft ob die
Strukturlänge stimmt, kann ein Angreifer indem er mehr Daten schreibt
als das Programm erwartet die Rücksprungadresse der Subroutine
überschreiben. Und da PCs nunmal von Neumann Maschinen sind und Daten
und Programme (anders als in den üblichen µC) im gleichen Speicher
untergebracht sind, kann man so, wenn man weiss wo die Daten liegen, die
Rücksprungadresse in den Datenbereich umbiegen.
Und da man selbst ja diese Daten übergeben hat, bestimmt man auch was
dort liegt. Zum Beispiel eben Code der irgendwas "Böses" macht. Der
läuft dann mit den Rechten des Programmes, das da eben grad läuft. Weil
das Programm eben der Ansicht ist, ohnehin nur "selbst" grad zu laufen.
Mit ASLR ist das natürlich jetzt viel komplexer geworden, weil es eben
schwerer (leider nicht unmöglich) wird vorherzusagen, wo denn die Daten
für den Rücksprung rumliegen werden.
Heinz L. schrieb:> Und da man selbst ja diese Daten übergeben hat, bestimmt man auch was> dort liegt. Zum Beispiel eben Code der irgendwas "Böses" macht.
dazu kommt aber noch die Hürde, das man Speichseite als nicht
"ausführbar" kennzeichnen kann. Dann kann diese code auch nicht einfach
gestartet werden.
Meinst Du damit das IMAGE_SCN_MEM_EXECUTE Flag aus dem PE-Header? Das
hat Windows noch nie wirklich dabei gestört irgendwas auszuführen.
Falls Du DEP meinst, ja, das wäre toll. Wenn's durchgängig funktionieren
würde. Meines Wissens ist nicht mal MS selbst vollständig "DEP-Konform".
Und spätestens bei diversen Kopierschutzverfahren mit
selbstmodifizierendem Code ist ohnehin Schluss.
Den größten Schutz in diesem Zusammenhang würde die ASLR bieten. Auch
weil diese nicht von der Kooperation anderer Softwarehersteller abhängig
ist. Wenn sie endlich richtig implementiert würde. Meine Fresse, sogar
die Gratiscodeklopfer von Linux haben's hinbekommen, aber MS eiert seit
3 Desktopversionen rum.
Heinz L. schrieb:> Meinst Du damit das IMAGE_SCN_MEM_EXECUTE Flag aus dem PE-Header? Das> hat Windows noch nie wirklich dabei gestört irgendwas auszuführen.>> Falls Du DEP meinst, ja, das wäre toll. Wenn's durchgängig funktionieren> würde. Meines Wissens ist nicht mal MS selbst vollständig "DEP-Konform".> Und spätestens bei diversen Kopierschutzverfahren mit> selbstmodifizierendem Code ist ohnehin Schluss.
naja, dann muss der Prozess halt ausführbaren Speicher reservieren.
Dafür müsste man aber diese Programm anpassen.
> Den größten Schutz in diesem Zusammenhang würde die ASLR bieten. Auch> weil diese nicht von der Kooperation anderer Softwarehersteller abhängig> ist. Wenn sie endlich richtig implementiert würde. Meine Fresse, sogar> die Gratiscodeklopfer von Linux haben's hinbekommen, aber MS eiert seit> 3 Desktopversionen rum.
ist doch schon seit Vista drin oder was meinst du?
Peter II schrieb:> ist doch schon seit Vista drin oder was meinst du?
Ist es. Vista, 7, 8 und jetzt bald 10. Mal gucken ob sie dort dann den
Zufallsgenerator so hingebogen haben dass er auch wirklich die
Adressräume zufällig vergibt.
Irgendwie scheint das für MS echt ein dramatisches Problem zu sein.
Egal, irgendwie glaub ich hilft das dem Threaderöffner jetzt nicht
unbedingt weiter. Die Frage ist eher... ja, was genau würde ihm
weiterhelfen?
Heinz L. schrieb:> Die Frage ist eher... ja, was genau würde ihm> weiterhelfen?
Leider oder Gottseidank ist Hacker noch keine anerkannte
Berufsausbildung, auch die Mafia veranstaltet da keine Seminare zur
Weiterbildung, sondern bedient sich einfach aus dem Pool derer, die sich
auf dem Gebiet selbst weitergebildet haben, wobei eine Ausbildung in
Systemprogrammierung durchaus eine gute Grundlage ist.
Der TO ist da schon auf dem richtigen Weg, bloss im falschen Forum, hier
ist nicht die Expertise vertreten, die er sucht. Ausserdem habe ich den
Eindruck, dass sein Grundlagenwissen nicht annähernd ausreicht: dass man
in Windows einfach in den Speicher einer anderen Anwendung schreiben
kann bloss weil die Adresse anscheinend gleich ist, ist schon sehr naiv.
Das ging noch unter CP/M im 64k-Adressraum.
Georg
Moin,
darauf möchte ich als TO doch noch mal antworten: Mir ist völlig klar,
dass der Ansatz des initialen Postings naiv ist - aber immerhin war er
der Auslöser für diesen Thread, in dem ja doch noch einige interessante
Beiträge gelandet sind. Zudem ging es mir um ein grundlegendes
Verständnis, und da wollte ich ein möglichst einfaches Beispiel als
Start wählen, das eben von allen möglichen, verkomplizierenden Themen,
abstrahiert. Das (Thema) wurde dann ja ein Selbstläufer ;-)
Außerdem (vgl. meinen Beitrag vom 10.04., 18:37) habe ich nicht wirklich
das Interesse, ein Hacker o.ä. zu werden, sondern möchte ein Gefühl
dafür kriegen, wie einfach es tatsächlich ist, sich Adminrechte zu
verschaffen. Die Qualität der Antworten hier im Forum zu allen möglichen
Fragen schätze ich i.d.R. sehr hoch ein - insofern sehe ich Euch als
Fachleute an. Danke dafür!
Für mich erhalte ich als Ergebnis eine Bestätigung meiner Vermutung,
dass die bloße Existenz einer Sicherheitslücke nicht ausreicht, um
Adminrechte zu bekommen und so den Rechner zu hacken. Vielmehr ist ein
tiefes Verständis und Kenntnis des jeweiligen Betriebssystems notwendig.
Wenn das ganze dann auch noch über das Netz durchgeführt werden soll,
existieren weitere Hürden.
Zurück zu der (pauschalen) Aussage, dass eh 95% aller Privatrechner
heute bereits gehackt seien (vgl. ebenfalls mein Posting vom 10.04.,
18:37): Sofern die "normalen" Sicherheitsvorkehrungen eingehalten werden
(Einspielen von Updates, Firewall, aktueller Virenscanner; nicht
bedenkenlos surfen bzw. auf Links (auch nicht in Mails) klicken, usw.),
gibt es keinen Grund zu der Annahme, der Rechner sei kompromittiert.
Denn wenn er es dennoch wäre, müsste jemand (=der Angreifer) entweder
verdammt viel Glück gehabt haben (Zufall), oder aber über sehr
umfangreiches Wissen verfügen; dieser (zeitliche) Aufwand ist bei einem
Privatrechner vermutlich eher nicht gerechtfertigt. Ob jetzt 95% aller
Privatleute sich auch tatsächlich sicherheitsbewusst verhalten, bzw. ob
die eigenen Daten im Netz ebenfalls sicher sind, sind zwei ganz andere
Fragen...
Georg schrieb:> Leider oder Gottseidank ist Hacker noch keine anerkannte> Berufsausbildung
Dochdoch, ist es. In Österreich zumindest kenne ich die Uni Hagenberg,
die ein Magisterstudium für Information Security Management anbietet.
Das umfasst zugegebenermaßen etwas mehr als "nur" das und schließt
natürlich auch Dinge wie IT Governance und ITSM ein, hat aber auch seine
technischen Seiten. Ist jetzt halt Österreich, würd mich aber wundern
wenn es sowas nicht auch schon in Deutschland gibt. Ausser Euer
Rollstuhlparanoiker hat den Boden dafür hinreichend vergiftet.
Gibt's halt noch nicht so lang, und alle "Alten" in dem Gewerbe haben
sich das Ganze halt mehr oder weniger autodidaktisch (mit ggf.
vorhandener "normaler" IT Ausbildung/Studium als Grundlage)
rangeschafft.
@Matthias (Gast): Nein, nur die Existenz so einer Sicherheitslücke
reicht nicht. Es würde aber auch das Problem auf die leichte Schulter
nehmen heißen, würde man jetzt annehmen dass dieses arkane Wissen nur
einem kleinen Kreis eingeweihter Druiden bekannt wäre und diese es nur
innerhalb ihres erlauchten Zirkels weitergeben würden. Erstens kann das
jeder problemlos per Google usw. in endlicher Zeit rausfinden und auch
lernen. Und selbst wenn nicht, dazu gibt's üblicherweise (wenngleich
auch nur gegen Einwurf kleiner Münzen) fertige Kits. Vergleichbar ist
das in etwa damit wie Spiele "gecrackt" werden. Können tun das nicht
sooo viele. Aber man muss nicht verstehen wie ein Crack funktioniert um
ein gecracktes Spiel zum Laufen zu bringen. Doppelclick auf das Programm
mit dem Namen Crack reicht dazu aus.
Ähnlich verhält es sich mit den Exploits. Ja, die Anzahl der Leute die
sowas wirklich selbst ausnutzen können ist eher überschaubar. Aber man
muss es nicht können um ein exploit-kit verwenden zu können.