«Mais ce n'est pas ennuyeux!» - telle est la devise informelle du personnel de notre centre de surveillance des menaces cybernétiques Solar JSOC (et je dois dire que 2019 y correspondait pleinement). Au début de la nouvelle année, beaucoup de gens aiment faire le point et se fixer de nouveaux objectifs, mais au lieu de cela, nous avons décidé de raconter quelques «horreurs de notre ville» - les cas de 2019, qui ont impressionné même les analystes expérimentés. La conclusion de ces histoires n'est qu'une: la technologie se développe et évolue, et la paresse, la négligence et la négligence humaines sont éternelles.
Wifi invité
Lors de la connexion des clients à la surveillance, nous demandons tout d'abord les informations les plus importantes: comptes critiques, groupes de domaines, segments non approuvés, adresses blanches, DMZ, sous-réseaux critiques, etc. Les sous-réseaux non approuvés ne sont que des réseaux Wi-Fi invités, ainsi que des réseaux de sous-traitants, des segments de test avec des autorisations pour autoriser tout, etc. très difficile, voire impossible. Sur le réseau du client, il n'y avait aucune possibilité de telles interactions, à l'exception de la page d'autorisation dans le réseau invité. Nous nous sommes calmés en ajoutant une interdiction d'interagir du Wi-Fi avec TOR, des serveurs C&C et d'autres mauvais esprits, afin que nous ne soyons pas bombardés d'opérations qui n'intéressaient pas le client potentiel (bien que nous ayons encore collecté des statistiques sur ces incidents pour des rapports de synthèse). Et le troisième matin du projet pilote, nous avons remarqué une anomalie: le flux d'événements du pare-feu a été multiplié par 4!
Ils ont commencé à chercher la cause du «blocage» et, avec surprise, l'ont trouvé dans le segment du Wi-Fi invité. Un certain hôte a généré 4 millions (!) D'événements par heure. Et les événements sont assez intéressants - connexions sur le port 445 à des adresses blanches aléatoires de l'espace Internet. Quatre millions, Karl!
Après en avoir informé le client, ils ont commencé à attendre des informations sur l'hôte et l'incident, puisque DHCP (c'est le serveur d'autorisation) n'était pas connecté à SIEM. Après environ 3-4 heures, le client a indiqué que l'hôte était un téléphone mobile. Dire que nous avons été surpris, c'est ne rien dire. Un téléphone portable ordinaire ne peut pas générer un tel flux d'événements. Ils ont commencé à découvrir les détails, et il s'est avéré que le téléphone portable n'avait rien à voir avec cela - quelqu'un vient d'utiliser l'un des appareils enregistrés comme couverture. Il n'a pas été possible de trouver la véritable source d'activité, et notre client a déclaré qu'il n'était pas intéressé par ce cas, donc l'activité a dû être minimisée. Néanmoins, nous avons averti les spécialistes du client des risques possibles: étant donné que l'activité (évidemment malveillante) provient de leurs adresses, ils peuvent, par exemple, entrer dans les listes des serveurs C&C des fournisseurs d'antivirus et recevoir des plaintes des forces de l'ordre (qui sait quelle infrastructure cet hôte va scanner - après tout, il peut y avoir KII, et l'analyse des vulnérabilités fait référence aux incidents qui doivent être signalés à GosSOPKA). Après de tels arguments, le client a tout de même décidé de comprendre plus en détail et de respecter nos recommandations. Et ils étaient les suivants:
- fermer tous les ports sauf 80 et 443 (cela s'est avéré être la bonne décision, car après 445 une analyse sur le port 22 a suivi),
- nous introduisons des restrictions sur la vitesse de l'Internet distribué,
- activer les puces UTM, y compris le contrôle des applications, et couper des catégories étranges comme les torrents, les navigateurs TOR, les scanners détectés, etc.,
- activez la limite du nombre de connexions par intervalle de temps.
Le client n'a jamais pu découvrir qui était cet utilisateur Wi-Fi actif, mais au moins, il l'a bloqué avec de l'oxygène (et, très probablement, l'attaquant est allé chercher le prochain Wi-Fi disponible.
Quelques mois plus tard, ce pilote a été clôturé avec succès et transféré au contrat, mais nous rencontrons toujours des cas similaires dans des entreprises complètement différentes, de sorte que les recommandations ci-dessus peuvent être classées comme universelles.
Par défaut, ou sabotage du fournisseur
Parallèlement à la connexion pilote à la surveillance Solar JSOC, le client a mis en service une nouvelle UTM. La migration a été échelonnée: d'abord transféré l'ACL sur les sous-réseaux, puis les politiques d'application. Le dessert est le plus intéressant.
Tout s'est passé selon les classiques - vendredi soir. La première ligne a enregistré des incidents en contactant l'infrastructure client pour les nœuds TOR, apparaissant comme C&C dans l'une des listes de diffusion FinCERT. Étant donné que le projet était un projet pilote et que le client a transféré tous les incidents à faible criticité, aucune carte d'incident n'était prévue, outre la notification par courrier, une carte d'incident. Par conséquent, la première opération à partir de différents hôtes vers une seule adresse, bien qu'elle ait suscité des soupçons parmi les ingénieurs de surveillance, n'a pas été intensifiée davantage. Lorsque le nombre de voyages a atteint trois, les gars ont senti que quelque chose n'allait pas et ont informé l'analyste qui avait amené l'incident au travail.
Tout d'abord, l'analyste a contacté les employés responsables du client et a suggéré de connecter les hôtes au niveau du journal local pour identifier la source d'activité. Au moment de la discussion avec les spécialistes du client, le nombre d'hôtes était passé à 7. La situation était très similaire à l'épidémie, mais l'antivirus sur les hôtes fonctionnait et était silencieux, il n'y avait aucune action active ni interaction d'hôte sur le réseau.
La connexion de trois hôtes au niveau du journal local n'a pas non plus permis de comprendre quel processus a généré l'activité. L'anxiété a augmenté, la seule option qui fonctionnait était l'isolement des hôtes avec la suppression parallèle d'un vidage de RAM et de l'image du disque dur. L'analyste a commencé à préparer des instructions et a en même temps décidé de rechercher sur Google l'adresse IP à laquelle les hôtes avaient accès pour la disponibilité dans d'autres mailings et incidents (car le type d'activité que nous avons observé était différent de celui décrit dans la newsletter FinCERT). Pour la plupart, l'idée est assez misérable, mais pas cette fois.
L'attention a été attirée sur l'article au titre duquel l'adresse IP et le nom du fournisseur UTM étaient répertoriés. Pour résumer l'essence de la publication, le vendeur a acheté une adresse IP qui appartenait auparavant au nœud TOR, qui figurait dans la newsletter FinCERT. Et ce n'est pas seulement tout! De plus, le vendeur a décidé de définir cette adresse par défaut pour la redirection de tous les appels suspects de l'infrastructure de ses clients vers des adresses potentiellement malveillantes. Autrement dit, toute connexion avec une adresse IP étrange a été interprétée par UTM comme illégitime et redirigée vers cette adresse miraculeuse.
Après avoir spécifié si le module de protection anti-malware est déjà activé et ayant reçu une confirmation, l'analyste et les spécialistes du client ont expiré.
PS L'analyse des échecs détectés par UTM confirme que les 7 activités étaient toutes fausses positives.
Nous avons promis des recommandations pour chaque cas, mais ici, peut-être, nous n'en donnerons qu'un: ne pas déployer vendredi. Et avertissez tous les intéressés et sympathisants.
Historiquement
Ce leitmotiv rassemble une grande variété de cas. Prenons l'exemple du déclassement. Souvent, les processus qui ont perdu leur pertinence dans les entreprises sont tout simplement oubliés: personne ne «analyse» l'ancienne infrastructure, laissant les anciennes machines virtuelles, les serveurs et les accès réseau. Dans le même temps, personne ne surveille les mises à jour, les antivirus et les événements sur ces hôtes, et même les administrateurs ne connaissent souvent pas les propriétaires des systèmes. Par conséquent, après un certain temps, ces éléments d'infrastructure ne présentent pas les surprises les plus agréables. Que coûte seulement l'envoi d'une télémétrie importante d'une organisation environnementale sur un projet achevé en 2005 à des serveurs FTP d'un pays non ami!
Souvent, personne ne s'occupe de l'entretien des systèmes vieux de 10 ans, bien qu'ils continuent d'être utilisés. Par exemple, un portail de réinitialisation de mot de passe qui utilise l'ancien moteur et pour la commodité des utilisateurs se penche sur Internet, ou RDP, dont l'entrepreneur a besoin pour configurer les applications commerciales et qui se prolonge pendant 5-6 ans.
L'existence de tels problèmes devient généralement connue lorsque:
- l'hôte a été piraté et le cryptage s'est produit avec une nouvelle extorsion (il y a eu beaucoup de tels incidents récemment),
- il y a une migration d'une solution sur le périmètre à une autre,
- on arrive au pilote et on recueille le profil des ports ouverts sur le périmètre.
Mais il y a aussi des situations complètement mythiques: en 2013, l'entreprise a construit un tunnel avec un entrepreneur au service de son système financier. Le contrat a pris fin, mais le tunnel est resté, car il a été réalisé par l'entreprise à laquelle le contractant a loué les locaux ainsi que l'infrastructure informatique. Une nouvelle entreprise a pris la même place et a été surprise de trouver les adresses disponibles des infrastructures d'autres personnes. La curiosité a pris le dessus, puis la tentation et la soif de profit. Ils ont déversé une base de données de contreparties et de contrats sur le bruit - le bénéfice de la concurrence était intéressant, mais personne n'a fait de bruit dans l'entreprise victime. L'histoire a duré plus d'un an (il n'a pas été possible de remonter le long des journaux), mais au final, l'enquête, les licenciements et la cerise sur le gâteau sont une affaire pénale.
AWOL, ou parce que c'est plus pratique
Le cas dans son ensemble est plutôt banal, ce qui ne peut être dit au sujet de la "méthodologie de mise en œuvre".
Étant donné:
- projet pilote de suivi des clients;
- sources connectées sur le périmètre, ainsi qu'entre les segments corporate et technologique;
- administrateur en service sur le lieu de travail et servant le segment de réseau fermé;
- le désir aigu de l’administrateur est de travailler moins, de dormir plus et de tout faire confortablement.
Comme je l'ai déjà dit, lors de la connexion, nous demandons au client diverses informations, y compris des adresses blanches, afin de collecter des statistiques sur les connexions avec lui à partir d'Internet et ainsi former un profil de périmètre externe. Après avoir créé une règle qui remplit la liste dans SIEM, dans environ une semaine ou deux, nous collectons des statistiques sur tous les ports ouverts sur le périmètre, les déchargeons au client, regardons et réparons ensemble (tout en fermant ce qui est illégitime). Rassemblant des informations pour le profil, nous avons périodiquement parcouru nos yeux à travers la liste, vérifiant que les ports sont ouverts à toutes ou seulement certaines adresses sur les listes blanches. L'attention a été attirée sur le port 43388, qui semblait anodin, mais a été diffusé en 3389 et l'adresse grise, dont le propriétaire nous était alors inconnu.
Lors de la vérification, il s'est avéré qu'il est fermé à nos adresses. Nous pensions qu'il était ouvert sur les listes blanches, mais pendant la journée, nous n'avons observé aucune connexion réussie avec lui. En arrivant le lendemain matin, ils ont de nouveau remarqué qu'un paquet d'événements était arrivé pendant la nuit. Cette fois, nous avons examiné de plus près les adresses sources et avons vu plusieurs sessions de Moscou d'une durée totale de plus de 5 heures et un assez grand nombre de courtes sessions du monde entier. Ensuite, il est devenu clair que le point n'était pas que le port n'était accessible qu'aux adresses de la liste blanche, mais qu'il n'ouvrait que la nuit - d'environ 00h00 à 06h00 du matin. Après avoir déterré les journaux du domaine et de l'antivirus (ils venaient d'être connectés à ce moment-là), nous avons été surpris de constater que l'adresse appartient à l'administrateur en service, qui devrait être sur le lieu de travail pendant cet intervalle de temps! Après avoir analysé les connexions de sa voiture, nous avons trouvé une autre situation intéressante: chaque soir, le port ouvrait également (je pense qu'il n'est pas difficile de deviner lequel) dans le segment dédié fermé. Il est presque impossible de remarquer une telle activité le quatrième jour du pilote, à ce moment-là, le nombre de connexions autorisées entre les segments est encore plus que les ports ouverts sur le périmètre. Après avoir informé les agents de sécurité de la situation, ils ont connecté l'hôte au niveau du journal local et se sont assurés que l'administrateur s'échappait tranquillement du travail. Il s'est avéré qu'il vivait presque dans une maison voisine, et la connexion à distance, bien sûr, est devenue trop tentante.
Peut-être que si l'administrateur décrivait la situation, il serait autorisé à travailler à distance via SKDPU, à condition qu'au moment de l'accident, il puisse venir travailler dans les 15 minutes et qu'il n'y aurait aucun problème.
Total
En réalité, l'une des principales menaces à la sécurité de l'information est le gougeage sur le terrain. Par conséquent, minimisez les risques:
- Gardez une trace des configurations de périmètre et de pare-feu.
- Essayez de rendre la télécommande dans une entreprise gérée (VPN via un serveur de terminaux). Et s'il existe déjà, contrôlez qui l'utilise (en supprimant divers RAT sur les hôtes qui détectent désormais facilement presque tous les moteurs antivirus).
- Suivez les actions des utilisateurs privilégiés: très souvent, ils perdent leur vigilance, croyant qu'ils ont tout sous contrôle, et facilitent l'accès des attaquants aux données critiques.