CONNAÎTRE! Création de logiciels espions, les virus informatiques et nasties similaires peut être illégal où vous vivez et est considéré comme très contraire à l'éthique par presque tout le monde. Pourtant, je dois poser pour sensibiliser la population sur la façon dont il est facile de créer un. Je demande cela après la W32 / Induc-A a été introduit dans ce monde par quelqu'un qui est venu avec une façon méchante à la propagation d'un. Donc, je veux savoir comment un virus peut être créé si je serai en mesure de les reconnaître à l'avenir!
Récemment, un nouveau virus a été découvert qui se propage lui-même en remplaçant les développeurs des copies de code bibliothèque. en fait, à travers le code source de Delphi 4 à 7. Qu'est-il arrivé est qu'il ya un virus dans la nature qui recherche l'ordinateur pour un fichier appelé SYSCONST.PAS, auquel elle s'ajouter code source. Ce fichier se trouve être un fichier source pour les bibliothèques d'exécution de Delphi. (Ce code source d'exécution est disponible pour les développeurs Delphi.) En conséquence, après avoir été infecté par un programmeur créerait beaucoup de nouvelles versions de ce virus sans même le savoir. Étant donné que les scanners de virus génèrent parfois des faux positifs de nombreux développeurs pourraient ainsi décider d'ignorer les avertissements du scanner et peut-être qu'ils vont même désactiver leur scanner pendant la construction de leur projet. Pour empirer les choses, leur projet pourrait même déclencher les scanners de leurs clients il est donc probable que les programmeurs ne seront pas vérifier leur code source, mais vont juste essayer de tromper le scanner en quelque sorte. Autrement dit, si un scanner de virus est même capable de reconnaître le virus, ce qui est peu probable. Ainsi, nous, les développeurs de logiciels peuvent être la création de virus sans se rendre compte de ce que nous faisons!
Alors, comment créer un virus? Simple: obtenir votre code source infecté par un virus et vous avez terminé
Bon, alors le code source de Delphi 4 à 7 pourrait être infecté. Tous les développeurs Delphi, s'il vous plaît vérifier vos fichiers source! Le cas est juste une preuve de concept et apparemment, il peut être un grand succès. En outre, la plupart des scanners de virus ne seront pas vérifier le code source, mais se concentrer uniquement sur executables. Ce virus peut rester indétectable pendant un certain temps.
Ce virus a également été couronnée de succès, car il mal utilisé le code source. Delphi est un projet commercial et le code source est disponible. Mais qui est sûr que ces pirates ne seront pas attaquer les projets open-source de la même façon? Il y a beaucoup de projets open-source là-bas et qui va les vérifier tout en vous assurant qu'ils sont tous se comporter d'une manière décente? Et si quelqu'un vérifie le code, il sera en mesure de reconnaître si quelque chose est un code malveillant?
Donc, pour nous assurer que nous pouvons reconnaître le code source malveillant, je dois demander: Comment Est-ce que je crée un virus? Comment puis-je reconnaître le code qui va créer un virus? Qu'est-ce que la plupart des logiciels malveillants voudra faire?
Il y a un peu de discussion sur le code source d'exécution Delphi, sur ce code étant open source ou non. Borland utilise une double licence pour leur code source à partir du moment où ils ont commencé à soutenir Linux avec Kylix. En conséquence, le code source est un symbole « GPL » a déclaré ce qui indique si les bibliothèques sont compilés sous forme de code GPL ou non. En GPL, le code source serait open source. Cela arrive aussi d'être la version source qui a été attaquée par le virus. Quoi qu'il en soit, pour éviter des discussions ici, j'ai demandé cette question ici afin que nous puissions concentrer davantage sur le problème du virus et moins sur Delphi. Au fond, nous parlons d'un virus qui code source des attaques. Techniquement, tout le code source pourrait être en danger, mais le code source ouvert est un candidat probable car les pirates savent sa structure et peuvent cibler les fichiers qui sont rarement modifiés, donc rarement vérifiées. (Et s'ils peuvent pirater leur chemin dans un système CVS, ils pourraient même effacer les traces de leurs modifications, donc on ne peut remarquer les modiifications!)
6 Réponses :
Si vous voulez vraiment apprendre et que vous êtes prêt à mettre à l'époque, votre temps est probablement mieux dépensé sur Google à trouver, puis participer à une communauté de Greyhat. Ce sujet est très complexe.
Si votre question est aussi simple que "Qu'est-ce qui est un moyen facile de reconnaître un virus de son code source", ce n'est probablement pas facile, car il y a des moyens infinis d'y aller.
Mais qu'en est-il de reconnaître leur comportement de manière générique? Par exemple, des modèles reconnaissables dans le code? Au moins, reconnaissable pour nous, les humains.
Il suit cependant que la conception de virus changerait pour éviter la détection.
J'ai récemment lu un livre sur les "mythes de la sécurité". Fondamentalement, il a déclaré que les virus deviennent difficiles à détecter non pas parce qu'ils sont nouveaux, mais parce qu'ils sont capables de se modifier par ex. Utilisation de techniques de cryptage et d'emballage. Un virus qui infecte le code open-source serait également difficile à détecter simplement car il devient une partie de nombreuses autres applications. Cependant, le problème le plus gros qu'il a une signature qui peut être reconnu, cependant.
Je l'ai vu être aussi simple que "=" au lieu de "==" dans un programme C. Il peut être impossible de dire la différence entre une faute de frappe et un trou de sécurité délibéré. En fin de compte, c'est ce que vous voulez vraiment, de toute façon: à tous identifier les problèmes de sécurité, pas seulement des problèmes de sécurité délibérés.
Bien que cela ne réponde pas vraiment à votre question, je pense qu'un papier vraiment intéressant à lire est Réflexions sur Trusting confiance par Ken Thompson. Il soulève un point fascinant que même si votre code source est exempt de défauts (virus, chevaux de Troie, etc.), vous pouvez toujours produire des exécutables défectueux si votre compilateur est défectueux . Et même si vous reconstruisez le compilateur du code source propre, vous pouvez toujours avoir le même problème.
Sauf si vous construisez votre ordinateur à partir de la terre avec vos propres microchips, assemblez à la main votre propre BIOS, rédaction de votre propre système d'exploitation, votre compilateur et votre logiciel, vous devez dessiner la ligne quelque part et confiance < / em> que le matériel et le logiciel sur lequel vous construisez vos systèmes sont corrects.
Eh bien, la confiance est ce qui compte. Mais comme cela est, un pirate informatique a décidé d'infecter un projet open source à la source! Cela sera copié par de nombreux autres pirates informatiques qui tenteront d'infecter plus de code source ouverte, dans la mesure du possible. Donc, tout d'abord, je veux créer une sensibilisation. Et aussi, je veux des conseils utiles sur la reconnaissance de ces extraits de code malveillants.
Un peu, cela est maintenant très pertinent avec les révélations actuelles Snowden / NSA.
David A. Wheeler a présenté un moyen de contrer l'attaque "confiance de confiance" avec une méthode appelée Divers double compilation < / a> dans sa thèse.
Vous pouvez vérifier le bit diabolique sur des paquets entrants ... http://en.wikipedia.org / wiki / evil_bit
Si vous souhaitez reconnaître les logiciels malveillants, vous devez savoir comment cela fonctionne. Cela signifie rechercher des logiciels malveillants et aquiver la compétence pour produire des logiciels malveillants.
Je ne fournirai pas de liens ici. Ils sont facilement trouvés cependant.
Vous demandez "Qu'est-ce que la plupart des logiciels malveillants voudront faire?".
Une excellente source pour ce type d'information est Le Hacker trimestriel , qui est si grand public, vous pouvez Trouvez-le dans votre librairie locale, ou Vous pouvez vous abonner en ligne pour vous faire envoyer votre envoi à vous . < / p>
Il a été commencé à aider les pirates et les physfulseurs partagent des informations. Il est encore très populaire avec des pirates informatiques aujourd'hui et est considéré par beaucoup d'être controversé dans la nature.
Le contenu du problème actuel comprend:
Il y a aussi Une excellente série d'articles sur le piratage chez Wikipedia et < Un href = "http://fr.wikipedia.org/wiki/computer_virus" rel = "Nofollow Noreferrer"> sur les virus informatiques .
... et oui, il est important que les programmeurs comprennent la manière dont les œuvres de piratage et de la rupture de codes, afin qu'ils puissent faire de leur mieux pour le contourner dans leurs programmes.
Nous devons également la comprendre afin que nous puissions la reconnaître dans le travail des autres! Avec la source fermée, il y a des risques de collègues qui ajoutent de codes malveillants, mais ces risques sont raisonnablement bien limités et plus faciles à tracer que les hacks du code source qui est disponible pour de nombreuses personnes, comme l'open source et la source d'exécution de Delphi. (Et pour être honnête, Delphi est très populaire parmi les pirates.)
Il n'y a pas de différence entre le code malveillant et un bogue de sécurité involontaire.
Vous pouvez aussi bien demander "Comment puis-je écrire un programme utile qui n'a pas de bugs et est impossible à exploiter".
Comme nous apprenons tous dans CS, il est impossible d'écrire des debuggers pour attraper des boucles infinies, sans parler de la malveillance intelligente.
Mon conseil pour les applications soucieuses de sécurité est un examen de code d'assignation EX (P | T) et l'utilisation du logiciel d'analyse statique disponible dans le commerce.
Oui il y a! Les punaises de sécurité sont cachées pour tout le monde. Le code malveillant est connu par une seule personne après son ajout, l'abus de ce code va commencer plus tôt. Bien que les punaises de sécurité soient mauvaises, le code malveillant est pire car ils vont être mal utilisés à partir du moment de la création. En outre, le code malveillant peut survenir dans n'importe quel fichier source. Ainsi, ils peuvent même être exploités par des applications qui n'ont rien à voir avec la sécurité.
Si mon intention n'était pas claire, je suis désolé. Ma réponse était destinée à être formée dans le contexte de la découverte du code malveillant et n'était pas destinée à aborder l'exploitation.
Parce que les informations peuvent être mal utilisées par des personnes non si intelligentes pour en créer un! Le virus iLoveYou n'a pas été créé par un pirate intelligent et malicieux, mais par un adolescent muet qui l'a créé et le libéré par accident. Je suis assez vieux pour se souvenir du virus de Noël Tree EXEC, qui a raté de havok en 1987, mais qui aussi était simplement créé comme une farce. C'est comme laisser votre enfant de 4 ans de jouer avec un pistolet chargé, sans surveillance. Souvent, rien de mal ne se produira mais ce n'est pas éthique ...
Désolé pour le pédantisme, mais pensez-vous pouvoir utiliser un terme autre que "open source?" Peut-être que quelque chose comme «source exposée» aurait votre point de vue sans que les gens potentiellement déroutants.
Le terme «open source» est préférable, car il est open-source qui est le plus susceptible d'être attaqué de cette façon. Le code source Delphi n'a pas été exposé, il est ouvert pour tous les développeurs Delphes. (Et les développeurs de constructeurs C #.) Plus de projets open-opt-source pourraient être à risque, surtout si certains changements malveillants ont été apportés à SourceFiles qui sont rarement modifiés ou vérifiés, mais qui sont toujours des parties de projets populaires.
Je ne suis pas d'accord que Open-Source est plus susceptible. Open Source est susceptible d'être visualisé par de nombreux autres développeurs que de code source fermé, et des projets open-source ont tendance à avoir une version de la version, Diffs, etc. Source fermée pourraient être visionnées par une seule personne. Ainsi, La source fermée peut être plus susceptible d'un code source Exploice . En tout état de cause, je n'irais pas beaucoup d'ouvrir la source.
L'open source a-t-elle vraiment vérifié que beaucoup de développeurs? Y a-t-il vraiment des développeurs qui vérifieront chaque fichier d'un projet composé de plus de 500 fichiers source? Est-ce qu'un fichier appelé syscirst.cpp, sysconst.cs, syscirst.pas ou sysconst.php sera vraiment vérifié pour un code malveillant, cela peut apparaître dans les 5000 constantes du fichier? Sûr! À une fois, quelqu'un va le découvrir. Pourrait prendre des jours, une semaine, des mois, encore plus longtemps. Là encore, même les malware réguliers sont découverts à temps, souvent trop tard.
@Alex: Pardonne-moi si je me trompe, mais vous semblez ne pas être très bien informé de la manière dont les logiciels open-sources fonctionnent. Il me semble que vous mettez en place beaucoup d'hommes de paille ici. Comment une modification qui introduit-elle une charge utile vraiment dangereuse (altération ou supprimer des fichiers exécutant le code d'exécution reçue sur une connexion réseau, des courriers relais ou d'autres trafic IP) n'est-elle pas évidente pour une inspection même occasionnelle du code? L'introduction des débordements de tampon serait beaucoup moins méfiant et il y a sûrement déjà déjà assez existant dans le code non géré qui pourrait être utilisé (AB) utilisé.
@gghie, ne doutez pas de mon expérience. Je vois un risque où quelqu'un a injecté de code malveillant dans un fichier source. Comme quelqu'un l'a déjà dit, Ken Thompson se demandait déjà s'il était possible d'introduire un virus au code en l'infectant à la source. (Ou plutôt, en infectant des fichiers .Obj.) C'était à l'autre année d'année 1984. Je vais plus loin et je me demande si cela sera remarqué suffisamment lorsque quelqu'un ajoute du code malveillant au code de l'open-source. Compte tenu du nombre de projets à Sourceforge.net, je ne pense pas qu'il est même possible de vérifier tous les fichiers open-source pour le code malveillant. Tôt ou tard, cela se produira.
@ALEX: Je ne vois toujours pas le problème. Les personnes ayant des droits de validation des projets SF.net ne sont probablement pas celles de commettre un code malveillant. Si vous avez peur de cela, vous devriez JAMAIS Exécuter un code tiers que vous n'avez pas examiné le code source de et je n'ai pas construit vous-même. C'est exactement la question de la confiance que le compilateur modifié augmente, et à ce sujet: pourquoi voudriez-vous faire confiance au compilateur Delphi, alors? Parce que ce n'est pas open source et que vous avez payé pour cela? Comment un référentiel OS bien exécuté pose-t-il des risques qu'un vendeur commercial n'aurait pas?
@gghie, le centre de mon Q est sur des pirates informatiques infectant des exécutables via le code source. Cet exemple de Delphi me semble être juste une preuve de concept et il semble réussir. La prochaine attaque pourrait être plus aléatoire dans le code infectant, mais je m'attends à une attaque suivante. Je fais déjà prudes avec des exécutables tiers. Maintenant, je suis aussi très prudent avec le code source tiers!
Ce n'est pas une question d'open-source vs source fermée. Le risque est juste un code source en général pouvant être infecté. Avec open-source, un tel virus se répandrait plus facilement, car d'autres pourraient afficher aveuglément la source du référentiel de code sans vérifier le contenu.