Archives de catégorie : Apache

Apache, Cyber-attaque, Cybersécurité, Entreprise, Fuite de données, Mise à jour, Patch, Piratage

299 failles corrigées par Oracle

Oracle corrige un total de 299 failles dont la vulnérabilité Struts dévoilée par les pirates de la NSA, Shadow Brokers.

Un total de 299 nouveaux correctifs de sécurité viennent d’être publiés par Oracle pour l’ensemble de ses gammes de produits. Cette mise à jour de sécurité corrige 25 instances de la tristement célèbre vulnérabilité qui sévissait au sein du composant Apache Struts et permettait à un attaquant distant de prendre le contrôle total du serveur exécutant Struts. Le correctif pour Struts a été appliqué à 19 instances de cette vulnérabilité qui affectaient Oracle Financial Services Applications ainsi que WebCenter, WebLogic, Siebel, Oracle Communications, MySQL et Oracle Retail.

Oracle a également publié le patch 25878798 pour Solaris 10 et 11.3 pour corriger l’exploit EXTREMEPARR (CVE-2017-3622), la deuxième vulnérabilité dévoilée par le groupe de pirates Shadow Brokers. Si elle est exploitée avec succès, la vulnérabilité EXTREMEPARR, avec un score de sévérité CVSS de 7,8 sur 10, facilite une élévation de privilèges locaux dans le composant « dtappgather ». L’autre vulnérabilité CVE-2017-3623 dévoilée par Shadow Brokers, baptisée « Ebbisland » ou « Ebbshave », a déjà été corrigée par Oracle lors de plusieurs distributions de patches pour Solaris 10, diffusées depuis le 26 janvier 2012 et elle n’affecte pas Solaris 11.

Sur un ensemble de 299 correctifs, MySQL, Financial Services, Retail et Fusion Middleware se taillent la part du lion des correctifs. La majorité des vulnérabilités au sein de Financial Services, Retail et Fusion Middleware étaient exploitables via le protocole HTTP, les attaquants pouvant prendre le contrôle total du système à distance sans avoir besoin d’aucun certificat.

Concernant les bases de données, le volume de vulnérabilités MySQL a sensiblement augmenté par rapport au serveur de base de données Oracle. Il en va de même pour la mise à jour des 39 correctifs pour MySQL, dont 11 exploitables à distance sans authentification. Soit un nombre important de failles par rapport aux 3 seuls problèmes affectant le serveur de base de données. Toutes les vulnérabilités pour MySQL étaient exploitables via le protocole MySQL utilisé par les systèmes clients pour se connecter au serveur de bases de données. Les entreprises devraient donc dresser un inventaire détaillé de leurs serveurs MySQL concernant leur exposition, que ce soit à l’intérieur ou à l’extérieur de l’entreprise.

Java SE a bénéficié de 8 correctifs de sécurité, notamment pour 7 vulnérabilités exploitables à distance sans authentification. AWT, JCE ainsi que d’autres composants réseau Java étaient affectés et susceptibles d’être exploités via FTP, SMTP et de nombreux autres protocoles. 21 produits Sun Systems ont été corrigés dont Solaris, l’appliance de stockage Sun ZFS et Solaris Cluster. Parmi ces derniers, 8 vulnérabilités étaient exploitables à distance. Le composant le plus affecté dans Oracle Linux était la solution de virtualisation Oracle VM Virtual Box avec 6 vulnérabilités exploitables à distance.

(Cf tableau – liste de vulnérabilités exploitables à distance et résolues par le pack de correctifs).

En résumé, il s’agit d’une mise à jour de sécurité d’envergure avec 299 correctifs publiés pour toute la gamme de produits Oracle, corrigeant la vulnérabilité Apache Struts embarquée dans certains produits, ainsi que 162 vulnérabilités exploitables à distance. (Publié par amolsarwate dans The Laws of Vulnerabilities)

Apache, Cyber-attaque, Cybersécurité, DDoS, Piratage

Les hébergeurs OVH et 123-Reg sous les coups de DDoS massifs

Le britannique 123-Reg et le Français OVH ont subit ces derniers jours des attaques massives ayant eu pour mission de bloquer leurs services et serveurs.

Les attaques DDoS ne baissent pas. Leurs intensités ont même une fâcheuse tendance à s’intensifier. Derniers cas en date, des Dénis de Services Distribués (D.D.o.S.) massifs ayant visé le Britannique 123-Reg et le Français OVH.

Pour les nordistes d’OVH, 520 Gbps qui n’ont pas impactés les services de l’entreprise « à chaque instant, on a entre 50 et 150 IP qui se font DDoS » souligne Octave Klaba, le patron d’OVH.

Pour l’Anglais 123-Reg, l’attaque aura durée toute la journée du 2 août. 30 Gbps qui ont impactés les services et les clients de l’hébergeur. A noter qu’un petit Gbps est plus que suffisant pour faire tomber un service web.

Le record DDoS, constaté par la société Arbor Network, est de 579 Gbps. Il a été constaté en ce débit 2016.

Qui derrière ces attaques ?

Les pirates utilisent de plus en plus des attaques DDoS comme moyen de chantage à l’encontre des entreprises. Des sociétés, plus que troubles, commercialisent aussi des systèmes « stresser » qui, sur le papier, sont censés permettre de tester vos propres systèmes face aux DDoS. Des stresser qui, pour quelques Euros, servent surtout à bloquer d’autres sites et serveurs, comme ce fût le cas cet été à l’encontre d’éditeurs de jeux vidéo.

Apache, Chiffrement, cryptage, Cybersécurité

Garantir la protection de la sécurité par DNS hybride : quelles sont les pré-requis et avantages ?

Plus l’utilisation d’Internet est intensive, plus le DNS devient important. S’agissant d’un service si important, il est étrange que le DNS soit pratiquement invisible. Nous comptons dessus pour tout et pourtant nous ne le traitons pas comme un service essentiel ; au lieu de cela, nous le paramétrons, puis nous l’ignorons. Quelques points de vigilances sérieux sont à prendre en compte.

Le DNS est trop important pour être ainsi sous-estimé. Il convient de le gérer soigneusement, de mettre au point une architecture de DNS qui soit évolutive et sécurisée. Or c’est cette dernière étape qui est à la fois la plus difficile et la plus importante. Si l’on considère le DNS comme le GPS d’Internet, il n’est pas surprenant qu’il soit la cible des criminels. Abattre un serveur DNS peut empêcher une entreprise d’accéder à des ressources en ligne, tandis qu’empoisonner et fausser les résultats peut permettre à un criminel de rediriger les utilisateurs vers un site conçu pour dérober leurs informations d’identification – en ouvrant les portes de l’entreprise au vol d’IP, ainsi qu’en permettant un accès sans entraves aux comptes en banque et autres services financiers.

Une identification des vulnérabilités
Il suffit de regarder les listes de vulnérabilité publiées régulièrement pour voir à quel point il est risqué de ne pas gérer son serveur de DNS. ISC, l’organisme open source qui gère le développement de BIND, publie régulièrement sa matrice de vulnérabilité et a signalé sept principaux problèmes au cours des trois derniers mois. Quiconque ne suit pas ces listes et ne met pas ses serveurs à jour laisse son entreprise grande ouverte aux menaces les plus diverses. La base de données nationale de vulnérabilité du NIST décrit dans le détail 14 vulnérabilités constatées dans différents produits du serveur DNS sur la même période.

Beaucoup de ces vulnérabilités étaient critiques : dans un cas, une requête DNS spécialement formatée pouvait planter un serveur, empêchant ainsi une entreprise, ses utilisateurs (et dans certains cas, ses clients) d’accéder à Internet ou à leurs applications. Ces vulnérabilités zero-day présentent un risque important car le DNS peut sembler être un service qui « se contente de fonctionner », mais un serveur de DNS non sécurisé est une porte ouverte qui n’attend qu’une chose : que les cambrioleurs d’Internet entrent. Excepté qu’il ne s’agit pas uniquement de la porte de l’entrepreneur, mais également des portes des salariés, des portes des clients et du coffre-fort de la banque. En fait, de tout ce qui est en ligne.

Alors, comment peut-on sécuriser son DNS ?
Une solution de DDI bien conçue est une possibilité. Certains éditeurs propose un service de DNS Hybride. Contrairement à la plupart des solutions de DNS, le DNS hybride utilise deux technologies de DNS différentes afin de réduire les risques pour les utilisateurs. Dès qu’une alerte est publiée, il est possible de passer de BIND à NLnet Labs (NSD/Unbound) en un seul clic et une fois qu’un patch a été oublié, il est possible de le tester, avant de l’envoyer en production dès le processus de validation terminé. Toutes les modifications apportées au DNS local étant gérées par le logiciel de l’éditeur, il est inutile de reconfigurer le reste de votre réseau.

Préserver la sécurité de l’infrastructure constitue une part important du travail d’un service informatique. Le DNS Hybride aide à simplifier le processus, en facilitant la gestion et le contrôle du DNS, tout en minimisant le risque, mais il est l’un des plus importants, ce qui minimise le risque de vulnérabilités aux attaques zero-day dans les technologies clés du réseau. L’infrastructure de DNS Hybride est également une extension des meilleures pratiques informatiques, qui utilise une combinaison de technologies pour gérer le risque.

Lorsqu’une infrastructure hybride est mise en place, si une technologie présente un risque ou est attaquée, la deuxième continue d’assurer le service et il est possible de basculer de la technologie attaquée à l’autre en une seconde. Le but ici, comme toujours, est de préserver la simplicité des opérations. Les outils de DDI facilitent la gestion des paramètres de DNS. Combinés avec le DNS Hybride, ils permettent de basculer d’un DNS non sécurisé à un serveur sécurisé dès que l’utilisateur est notifié. Il peut ensuite rebasculer une fois le système mis à jour. Simple et sécurisée : cette méthode permet de préserver le DNS contre les pirates informatiques et de garantir que les données les plus précieuses atteignent la destination souhaitée. Tout en préservant l’entreprise contre les attaques zero-day destructrices. (Par Hervé DHELIN, EfficientIP)

Apache, Cybersécurité, Logiciels, Mise à jour, Patch, Tor

Quand un serveur Apache permet de surveiller un site TOR

Cacher un site Internet via TOR est simple. Au lieu d’un 92829.com, vous vous retrouvez avec un 92829.onion. Impossible, normalement, de trouver la moindre information sur l’hébergement, le propriétaire. Sauf si ce dernier les donne ou utilise un serveur Apache mal configuré.

Shaun, chercheur en sécurité informatique, vient d’expliquer sur son blog, comment il devient simple de remonter à un serveur caché sous TOR à partir d’un problème de configuration d’Apache. L’inventeur de la « faille » indique qu’il faut désactiver « mod_status » avec l’instruction: $ a2dismod status. Dans la plupart des distributions Apache proposées, « mod_status » est activé d’origine. Bilan, les informations sur le serveur s’affichent. Un outil accessible uniquement depuis localhost. Ca c’est pour la sécurité. Sauf que si le daemon Tor tourne en localhost, les sites, forums, blogs tournant en .onion affichent leurs statistiques, les liens exploités, … Il suffit de taper, dans le navigateur TOR http://your.onion/server-status pour savoir si votre site, blog, forum est en danger.

Apache, Banque, Chiffrement, cryptage, Cybersécurité, Entreprise, Fuite de données, Paiement en ligne

Vulnérabilité des clés SSH et cybercriminalité : comment sécuriser et protéger les systèmes et environnements SSH

La réutilisation de clés SSH (Secure Shell) n’a rien de nouveau, c’est un phénomène que nous avons déjà observé dans le passé. Pour preuve, en 2013, les médias révélaient que des cybercriminels avaient profité de la vulnérabilité d’une clé SSH pour bénéficier d’un accès root aux équipements exécutant l’EAS (Emergency Alert System) aux États-Unis. Par Kevin Bocek, Vice President of Security Strategy & Threat Intelligence chez Venafi.

Le protocole SSH ayant pour mission de sécuriser les communications entre les ressources numériques les plus stratégiques et les plus précieuses d’une entreprise, il n’est guère étonnant que des cybercriminels veuillent dérober, déchiffrer ou autrement compromettre les clés cryptographiques sur lesquelles il repose. Les accès SSH sont tous tributaires d’une administration et d’une sécurisation adaptées des clés SSH. En l’absence de projet sérieux en la matière, votre établissement court un risque.

La compromission d’un procédé cryptographique au travers d’une clé SSH est, de loin, l’un des pires scénarios pour une entreprise. À partir du moment où un pirate possède un accès de niveau root, autrement dit un accès privilégié, il détient les clés lui permettant de prendre le contrôle d’un réseau ou d’un système complet pour le compromettre à sa guise. La plupart des professionnels de l’informatique et de la sécurité ne prennent pas conscience que les clés SSH en plus de fournir un accès de niveau root n’expirent pas. Par conséquent, à partir du moment où un pirate a dérobé une clé SSH, il disposera perpétuellement d’un accès par un moyen ou un autre. Il est donc primordial que les entreprises agissent aujourd’hui pour protéger leurs clés SSH.

Une étude(1) révèle que 3 acteurs du classement Global2000 sur 4 ne disposent d’aucun système de sécurité pour le protocole SSH, ce qui laisse ainsi la porte ouverte aux piratages, accès de niveau root et compromissions de données, et près de la moitié de l’ensemble des entreprises n’opèrent jamais de rotation ni ne changent leurs clés SSH. Ce faisant, leurs réseaux, serveurs et systèmes cloud deviennent la proie d’acteurs malveillants dès l’instant où ces clés SSH sont dérobées et utilisées de manière abusive.

Parce que le protocole SSH joue un rôle essentiel dans la sécurisation de l’accès administratif et automatisé à un large éventail de systèmes au sein d’établissements de toutes tailles, il est essentiel de disposer d’un ensemble très complet de chartes, processus et contrôles techniques pour gérer et superviser la configuration et les clés SSH. Il est donc important de sensibiliser à l’importance de sécuriser et de protéger ces clés SSH. Première action décisive que doivent engager les entreprises : maîtriser les clés dont elles ont l’usage – non seulement au niveau des systèmes et des logiciels installés, mais aussi des appliances réseau employées.

Le NIST(2) (National Institute of Standards and Technology) a publié récemment une nouvelle publication, « Security of Interactive and Automated Access Management using Secure Shell (SSH) » qui analyse plusieurs aspects décisifs du protocole SSH, notamment ses technologies sous-jacentes, vulnérabilités inhérentes ainsi que les meilleures pratiques appliquées à la gestion de clés SSH tout au long de leur cycle de vie. Ce rapport(3) sensibilise aux principales vulnérabilités associées à la gestion des clés SSH et de présenter des mesures concrètes pour sécuriser et protéger les systèmes et environnements SSH.

Parmi les quelques compromissions SSH notables ces dernières années figurent celles ci-après :
En 2014, Kaspersky Labs a mis au jour une cybermenace baptisée The Mask (ou Careto) qui a sévi sept années durant lesquelles un groupe criminel organisé en Espagne a multiplié les techniques pour mener des attaques de type APT visant à dérober des données à des administrations et des entreprises. Ce groupe s’emparait de clés SSH servant à l’authentification d’administrateurs, de serveurs, de machines virtuelles et de services cloud.

En juin 2015, Cisco a annoncé qu’une clé SSH autorisée par défaut était déployée sur trois de ses appliances de sécurité, exposant ainsi ses clients au risque de voir un pirate distant non authentifié intercepter du trafic ou accéder à des systèmes vulnérables au moyen de privilèges root.

La publication du NIST expose plusieurs vulnérabilités SSH courantes au sein des entreprises, à savoir :
– Implémentation SSH vulnérable
– Contrôles d’accès mal configurés
– Vol, fuite, détournement et non révocation de clés SSH
– Portes dérobées (clés utilisateurs non contrôlées)
– Utilisation indésirable des clés utilisateurs
– Rotation
– Déficit de connaissances et erreurs humaines

Le NIST recommande plusieurs mesures pour gérer les clés SSH, à savoir :

– Définir des principes et pratiques applicables au cycle de vie et à la révocation de clés SSH. La configuration de l’accès à un compte dans l’optique de faciliter les échanges avec les utilisateurs et d’automatiser les processus doit être une décision mûrement réfléchie, conciliant au mieux impératifs d’accessibilité et risques, qui doit tenir compte du niveau d’accès requis.
– Instaurer des procédures de contrôle et de surveillance continue. La surveillance continue a pour objet de faire en sorte que les procédures d’allocation, de gestion du cycle de vie et de révocation soient observées et appliquées. Des clés SSH non autorisées et mal configurées seront détectées.
– Inventorier les serveurs et clés SSH ainsi que les relations de confiance, et remédier aux problèmes éventuels. Les clés existantes au format propriétaire posent un réel problème de sécurité et compliquent l’analyse des risques si elles ne sont pas maîtrisées. L’emplacement de toutes les clés SSH existantes doit être inventorié, au même titre que les relations de confiance, qu’il convient d’évaluer à l’aune de politiques bien définies.
– Automatiser les processus. L’automatisation des processus relevant de la gestion des accès à partir de clés SSH est de nature à améliorer considérablement la sécurité, l’efficacité et la disponibilité.
– Sensibiliser la direction. Nombre de hauts responsables ne sont conscients ni du rôle central joué par les clés SSH dans le mode opératoire d’une infrastructure stratégique, ni des failles importantes susceptibles d’apparaître si celles-ci sont détournées. Sans formation suffisante des responsables opérationnels et chargés de sécurité, les initiatives de gestion des clés SSH risquent d’être évincées par des priorités de degré plus élevé, rendant ainsi l’entreprise plus vulnérable.

1 : Enquête 2015 Cost of Failed Trust Report publiée en mars dernier par Ponemon Institute et Venafi.
2 : Fondé en 1901, le NIST est une agence fédérale non réglementaire qui relève de l’administration de la technologie du département du Commerce des États-Unis.
3 : Co-signé par Venafi.

Apache, Cybersécurité, Fuite de données, Paiement en ligne, Patch, Sauvegarde

Malware pour les serveurs IIS

Un code malveillant capable de subtiliser mots de passe et informations bancaires via des serveurs IIS infiltrés. La société Trustwave, spécialiste en sécurité informatique, a lancé une alerte, mi décembre, concernant une découverte assez troublante. Une nouvelle attaque sournoise, via un malware, vise les serveurs IIS.

Baptisé ISN, le « machin » vise les machines Microsoft IIS6 32-Bit, IIS6 64-Bit, IIS7+ 32-Bit, IIS7+ 64-Bit. Le code malveillant, une fois installé, intercepte les requêtes POST http qu’il sauvegarde dans un fichier que le pirate peut consulter, à distance. Autant dire que les informations collectées peuvent faire de gros dégâts.

Comme le rappel Developpez, le chiffrement ne constitue en rien une méthode de protection efficace contre ISN, puisque le malware installé dans le serveur a accès aux données de la requête POST en clair. Au moment de l’alerte, seulement 9 antivirus sur 49 avaient detecté l’outil pirate qui installait ISN. Fin décembre, 31 sur 49.

Apache, Cyber-attaque, Cybersécurité, Patch

Outil pirate pour compromettre le Framework Web Apache Struts

3 commentaires

Un outil pirate Chinois, datasecuritybreach.fr a appris qu’il était vendu dans le black market, permet d’automatiser une attaque à l’encontre du Framework Web Apache Struts. Les chercheurs de l’éditeur de solutions de sécurité informatique Trend Micro confirme que cet outil était capable de compromettre le Framework Web Apache Struts en exploitant une faille qui vient d’être bouchée par l’Apache Software Foundation. L’outil pirate contient un  Web Shell, un outil qui permet au pirate de se promener dans la machine piégée via cette porte cachée. Une sorte de Shell99 bien connu chez les pirates. Une version java de la bestiole (JspWebShell) permet d’utiliser les technologies JavaServer Pages (JSP) pour les faciliter les actions du pirate.

Un « couteau Suisse » gênant. Même si un rustine existe, peu de mises à jour semblent avoir été effectuées par les utilisateurs de l’outil de développement d’applications web Java. Il faut dire aussi qu’en pleine périodes de vacances, ça n’aide pas. Comme le précise Trend Micro, l’outil pirate exploite les récentes failles CVE-2013-2251 et CVE-2013-1966, ainsi que de vieilles dames, toujours actives, datant de 2010 et 2011 : CVE-2011-3923, et CVE-2010-1870.

Bref, la mise à jour vers la version 2.3.15.1 d’Apache Struts est plus que conseillée : http://struts.apache.org/download.cgi#struts23151. DataSecurityBreach.fr a pu constater sur le blog du groupe de hackers chinois que les premières infos sur la faille ont commencé à pointer le bout de leurs bits en mai 2013. Le 19 Juillet sortait l’exploit. Le 20 juillet, l’outil K-eight, signé par B.L.Brother, était diffusé. Soit trois jours après la diffusion du patch de sécurité d’Apache.