Retour d’expérience sur quelques épreuves de Hack.lu 2013

Magazine
Marque
MISC
Numéro
73
Mois de parution
mai 2014
Spécialité(s)


Résumé

Les conférences en sécurité informatique organisent régulièrement des challenges – ou CTF - qui consistent à réussir des épreuves de différents types : récupération de données sur des serveurs web, compréhension d'un fichier exécutable, etc. Nous avons récemment participé au CTF de la conférence Hack.lu 2013. Notre équipe de trois ingénieurs/chercheurs a terminé dans le « Hall of Fame » des équipes locales. Nous vous donnons dans cet article un aperçu de quelques épreuves types que nous avons réussies.


Body

1. Introduction

Les CTF – Capture the Flag – sont des challenges de sécurité dans lesquels les équipes de hackers s'affrontent pour réussir le maximum d'épreuves en un temps limité. Les équipes sont constituées de un à une dizaine de hackers (et parfois plus). Les épreuves comportent chacune un score permettant de classer les équipes. Il est assez fréquent que ces compétitions aient lieu lors de conférences liées à des problématiques de sécurité ou cybercriminalité, et notamment sur les techniques de protection des infrastructures informatique et réseau : lutte contre les malwares, contre les intrusions...

Les épreuves se situent en général dans quatre domaines :

  • Le décryptage d'un texte chiffré. Il s'agit alors de trouver une ruse pour le déchiffrer, avec en général quelques indices fournis. Dans la très grande majorité des cas, une attaque « brute-force » est bien entendu inefficace.
  • L'attaque d'un site Internet. La solution passe par l'utilisation de failles au niveau du serveur : faille dans la sécurisation de la base de données (injections SQL), faille dans le serveur web (exemple : faille connue, mais non patchée), faille dans l'installation de l'ordinateur hébergeant le service web.
  • Exécutable. Un fichier exécutable est fourni en format elf par exemple. L'exécution de ce fichier se traduit par la demande d'un mot de passe, ou d'une clé pour l'exécuter. Il faut alors comprendre le code assembleur du fichier exécutable (rétro-ingénierie).
  • Divers. Il s'agit de tous les autres challenges ;) Parfois, ces épreuves sont reliées à un matériel spécifique (Arduino, Teensy...), ou dans un registre complètement différent en nécessitant par exemple du social engineering ou l'élaboration d'une vidéo.

Nous détaillons par la suite quelques challenges que nous avons réussis dans le cadre du CTF de la conférence Hack.Lu 2013 [1]. Le CTF était organisé par les Fluxfingers, une équipe renommée de hackers habitués aux CTFs puisqu'ils ont terminé l'année 2013 au douzième rang mondial. Plus de 700 équipes étaient engagées dans ce challenge qui a duré 48h. L'objectif de chaque challenge était de trouver un jeton à entrer sur le site Internet du CTF : l'entrée de ce jeton créditait l'équipe d'un certain nombre de points a priori proportionnel à la difficulté de l'épreuve en question. Comme dans tout CTF, il n'était ni autorisé aux équipes de se communiquer des résultats, ni d'attaquer le serveur central des challenges.

2. « Geolocation Flag » : accéder à un site Internet depuisun maximum de pays différents

Une épreuve consistait à accéder à une URL depuis différents pays du monde. Pour chaque accès depuis un pays différent, l'équipe recevait 1 point. Pour notre part, nous avons utilisé les techniques suivantes :

1. Le montage de connexions via le réseau Tor (Outil Vidalia), et la connexion à cette URL. L'ensemble était réalisé par un script « fait maison »: attente qu'une connexion Tor soit montée, accès au site Internet, arrêt de la connexion, etc. L'approche a bien fonctionné, mais n'a permis de faire des accès que depuis des pays qui possèdent des utilisateurs créant des nœuds Tor, surtout des pays en Europe et en Amérique du Nord. Une trentaine d'accès ont pu être réalisés grâce à cette technique.

Le script est le suivant (bash, Mac OS X) :

#!/bin/bash

RANGE=5
CPT=0
#TORSOCKS_CONF_FILE=$HOME/torsocks.conf

#echo $TORSOCKS_CONF_FILE

while true
do
    echo "Starting vidalia"
    open /Applications/TorBrowser_en-US.app/Contents/MacOS/Vidalia.app
    echo "Waiting for Tor connection"
    sleep 15
    echo "Getting CTF page"
    rm $HOME/tmp/2Y*
    cd $HOME/tmp; torsocks wget --no-check-certificate https://149.13.33.74/ref/2Y1McRL2MvhPUt5
    echo "Got CTF page"
    killall Vidalia
    sleep 1
done

Ce script peut être amélioré en backlistant progressivement les pays acquis des points de sortie Tor, au niveau du fichier torrc :

ExcludeExitNodes {au},{be},{br},{ca}, ...

2. L'utilisation de web-proxies situés dans des pays différents. Ces proxies se trouvent aisément sur les moteurs de recherche classique. Cette approche manuelle s'est révélée assez fastidieuse : beaucoup de ces proxies ont une durée de vie très courte, d'où le nombre élevé de coups d'épée dans l'eau… mais cette technique nous a permis d'accéder à presque 80 pays.

Une équipe qui a pu obtenir plus de pays que nous – typiquement, des pays peu ouverts ou petits, par exemple Saint-Vincent-et-les-Grenadines (.vc) - a utilisé une approche originale – mais peu éthique ? - : l'envoi d'un e-mail à des hôtels situés dans ces pays pour une demande de disponibilités de chambre. Cet e-mail contenait un lien masqué vers l'URL à valider depuis différents pays...

3. « Robot Plans » : comprendre une image Android

Une des épreuves expliquait avec humour avoir capturé un robot alors qu'il était en train de se soulager dans un buisson, puis l'avoir interrogé, et finalement n'avoir réussi qu'à en tirer son « module de communication Android ». La pièce jointe, image.tar.gz, n'est autre que le contenu d'un système de fichiers Android. Le décompresser ne pose aucun problème, mais où donc chercher un indice, un mot de passe ? Il y a tant de fichiers ! Nous avons regardé le contenu de la carte mémoire (/mnt/sdcard) pour y trouver des templates Word ou Excel sans intérêt, et aussi la ROM d'un jeu Game Boy Advance. Nous avons même poussé le vice jusqu'à exécuter ce jeu dans un émulateur – merci pour la super partie de Mario – mais ceci ne nous a pas aidés à trouver le mot de passe.

Nous avons fini par trouver un indice dans /data/system/gesture.key :

h.a.h.a.c.a.n.t.g.e.t.m.e.i.m.a.d.e.b.a.c.k.u.p.z.z.

Au passage, remarquez la présence de points entre chaque lettre, ce qui déjoue les recherches de chaînes de caractères (par exemple, nous avions évidemment cherché passwd, password, hack.lu etc. dans l'image du système de fichiers).

Sous Android, le fichier gesture.key sert théoriquement à mémoriser les mouvements qui permettent de déverrouiller le téléphone. Le téléphone comporte 9 points virtuels et ces mouvements indiquent dans quel sens les connecter. Les mouvements sont sauvegardés dans le fichier gesture.key, hashés par l'algorithme SHA1. Si cela vous intéresse, l'encodage des mouvements est très bien illustré dans [3].

Hélas, nous n'avons pas le contenu réel de gesture.key. Un indice cependant : « backup ». Nous allons donc voir les fichiers présents dans /data/backup. On constate alors qu'ils contiennent tous quelque chose qui ressemble énormément à un hash SHA-1 :

./image/data/backup $ cat 0ytutd 
06c65f3452c48504305234dc005f5efbeb3d185f
./image/data/backup $ cat 4bm94d 
960530aaddf48e841afe6e4b34b913effc92554f

Nous pensons alors que ces hash correspondent aux fameux mouvements qui ont été effacés de gesture.key. Il faut trouver à quel mouvement correspond tel hash - ceci étant facilité par l'existence de rainbow tables à cet usage sur Internet – puis dessiner les mouvements correspondants. Cette opération est grandement facilitée par [4] qui va jusqu'à dessiner le mouvement pour nous à l'écran.

capture1-s 0

Figure 1

Nous avons donc toute une collection de mouvements qui semblent dessiner des chiffres: 6, 7, 8, 7, 8, 7... Forcément, cela doit encoder le mot de passe à trouver. Mais dans quel ordre prendre ces mouvements ? Nous remarquons alors que tous les fichiers de backup ne sont pas créés exactement à la même heure. Il paraît logique de commencer par les premiers créés et de terminer par les plus récents. Nous ordonnons les mouvements : 7, 5, 7, 3, 7, 6… Pris deux par deux, cela nous fait penser à de l'ASCII : 75=K, 73=I, 76=L, etc. Au final, nous obtenons le message:

KILL_ALL_HUMANS

Méchants robots ! Et voilà ce qui permet de valider l'épreuve... (Hélas, dans notre cas, nous avons terminé cette étape 10 minutes après la fin du challenge et n'avons donc pas pris les points. Dommage !).

4. « RoboAuth » : la rétro-ingénierie d'un fichier exécutable Windows

Dans cette épreuve, on nous fournit un fichier, nommé RoboAuth.exe, et on sait qu'il faut saisir deux mots de passe (password1_password2) pour valider l'épreuve.

RoboAuth.exe est un exécutable Windows qui requiert un premier mot de passe. Dès que l'on se trompe, l'exécution se termine.

capture2-s 0

Figure 2

Une première inspection en hexadécimal du binaire ne révèle aucun mot de passe. Nous démarrons donc un désassembleur (OllyDbg ou IDA Pro, par exemple) et examinons l'assembleur. Il est facile de repérer la chaîne « You passed level1! » et l'on regarde où elle est utilisée :

.text:00401B59     lea     eax, [ebp+var_143]  ; contient le mot de passe attendu
.text:00401B5F     mov     [esp+164h+var_160], eax
.text:00401B63     lea     eax, [ebp+var_157]  ; mot de passe saisi par l'utilisateur
.text:00401B69     mov     [esp+164h+var_164], eax
.text:00401B6C     call    strcmp              ; comparaison
.text:00401B71     test    eax, eax            ; sont-ils identiques ?
.text:00401B73     jnz     short loc_401B8D    ; quitter si mauvais mot de passe
.text:00401B75     mov     [esp+164h+var_164], offset aYouPassedLevel ; "You passed level1!"

Tout de suite, on comprend que le programme compare (strcmp) la chaîne attendue avec la chaîne saisie, et affiche le message d'encouragement si elles sont identiques. Il suffit alors de mettre un point d'arrêt sur la comparaison, d'exécuter le programme et inspecter les valeurs en mémoire pour y trouver le sésame :

capture3

Figure 3

Mais alors, pourquoi ne voyait-on pas cette chaîne r0b0RUlez! ? Parce qu'elle n'est pas écrite telle quelle dans l'exécutable. Dans le code ci-dessus, le mot de passe attendu se trouve dans var_143. Or, en regardant plus haut, on trouve ces instructions :

.text:00401A71    mov [ebp+var_143], '0b0r'
.text:00401A7B    mov [ebp+var_13F], 'elUR'
.text:00401A85    mov [ebp+var_13B], '!z'

Cela explique tout ! Le mot de passe était présent, mais en 3 tronçons et nous ne l'avions pas remarqué. Il était là pourtant, sous nos yeux et même un hexdump aurait pu nous mettre sur la voie :

00000e70  00 c7 85 bd fe ff ff 72  30 62 30 c7 85 c1 fe ff  |.......r0b0.....|
00000e80  ff 52 55 6c 65 66 c7 85  c5 fe ff ff 7a 21 c6 85  |.RUlef......z!..|

Le programme passe alors dans une deuxième routine qui demande un deuxième mot de passe. Là, ça se corse un peu. Le programme appelle l'interruption 3. Cette interruption x86, appelée « Trap to Debugger » en anglais, permet de créer un point d'arrêt logiciel et complique un peu notre tâche d'exécution pas à pas dans un désassembleur. Il suffit de se positionner plus loin dans le code : il y a une boucle qui compare caractère par caractère le deuxième mot de passe attendu avec le mot de passe fourni. Nous y plaçons un point d'arrêt, et pour chaque caractère, nous notons la valeur attendue. Au passage, notez la présence d'une opération « XOR 2 » en guise de « chiffrement » de chaque caractère du deuxième mot de passe.

.text:0040154C comparaison:                            
.text:0040154C                 mov     eax, [ebp+arg_0] ; mettre un point d'arret
.text:0040154F                 movzx   edx, byte ptr [eax]
.text:00401552                 mov     eax, [ebp+arg_4]
.text:00401555                 movzx   eax, byte ptr [eax]
.text:00401558                 xor     eax, 2          ; "dechiffrement" du caractere
.text:0040155B                 cmp     dl, al          ; comparer les 2 caracteres
.text:0040155D                 jz      short suivant   ; mettre un point d'arret
.text:0040155F                 mov     eax, 1
.text:00401564                 jmp     short erreur_quitter
.text:00401566 suivant:                                
.text:00401566                 add     [ebp+arg_0], 1  ; mettre un point d'arret
.text:0040156A                 add     [ebp+arg_4], 1
.text:0040156E lecture:                               
.text:0040156E                 mov     eax, [ebp+arg_4]
.text:00401571                 movzx   eax, byte ptr [eax]
.text:00401574                 cmp     al, 2
.text:00401576                 jnz     short comparaison ; mettre un point d'arret
.text:00401578                 mov     eax, 0

Comme la procédure de vérification termine le programme à la moindre erreur, il est nécessaire avant chaque comparaison de modifier en mémoire la valeur saisie (nous avons entré n'importe quoi) pour qu'elle corresponde à la valeur attendue.

Heureusement, le mot de passe n'est pas trop long, et au final, nous trouvons le 2ème mot de passe : w3lld0ne.

Pour valider l'épreuve, il ne nous reste plus qu'à envoyer au serveur r0b0RUlez!_w3lld0ne.

5. « Packed » : retro-ingénierie et cryptographie

Un fichier nommé « packed » est fourni. Son examen permet de comprendre qu'il contient les parties suivantes :

  • d'abord une première séquence vide ;
  • puis la chaîne : #disabled-encoding: _rot___[...]__13 ;
  • puis une séquence binaire ;
  • puis un fichier PDF ;
  • puis une séquence de caractères « bizarres » (« chiffrés » en rot13) ;
  • puis un fichier encodé.

L'extraction du contenu du fichier PDF ne révèle a priori rien, et son ouverture permet de visualiser un « No hint given ». La dernière partie est un fichier ODT encodé en base 64. Son ouverture avec LibreOffice permet d'afficher un « Still no hint given » et son contenu ne semble rien cacher de particulier.

Nous nous sommes donc focalisés sur la partie en rot13. Elle contient le code python suivant :

cipher="H51\\\'Ux2J&+(3Z;Uxcx0Xxs\x13h\x014$V!R($R>\t/)R!\x01<.\x13,N-aP4M4aRuG1-VuU0 GuH+a@0W=3R9\x01>(_0\x01,8C0Rx GuN6\"V|\x1ezKZ3\x014$]}R!2\x1d4S?7\x1au\x1fxs\t_\x01xa\x13<Gx)R&Ip2J&\x0f93T#zj\x1c\x1ap\x13rk\x00g\x01e|\x13g\x19ju\x0ba\x18jt\x02o+xa\x13u\x01xa\x13%S1/Gu\x03\x1b.\\:N7.\\:N4o\x13\x0cN-3\x133M9&\x13<Rx A2WjiZ{DvaX0Xjh\x136N6\"R!\x01\x07rC0p\x138a\x1dc22ieu\x161Fw+=-@0\x1bRa\x13u\x01(3Z;UxcR\'F.s\x1c>D!s\x13<Rx,Z&R1/Tw+R"

n=0; import hashlib, sys;
try: key = sys.argv[1]    
except IndexError: sys.exit ("x\x9c\xf3N\xadT0T\xc8\xcd,.\xce\xccKW\xc8\xccSH,J/\x03\x00M\x97\x07\\".decode("mvc"))
f =getattr (hashlib ,"x\x9c\xcbM1\x05\x00\x02G\x01\x07".decode("mvc"))

while n < (5 *10 **6 ): key = (f (key ).digest ()); n = n +1 

key = key[:5 ].upper()
while len (key )< len (cipher ): key = key * 2 
plain = "".join (map (chr ,[ord (a)^ord (b)for a ,b in zip (cipher, key)]))

try: exec plain 
except: print "x\x9c\x0b/\xca\xcfKW\xf0N\xadT\x04\x00\x14d\x03x".decode ("mvc"), repr(plain)

On notera que le code ci-dessus n'est pas directement utilisable, car la chaîne "mvc" qui apparaît à plusieurs reprises est elle-même codée en rot13 et doit donc être remplacée par "zip").

La variable cipher de ce code python comporte un texte chiffré. Le programme prend une clé en entrée, puis l'utilise pour déchiffrer le message avec un algorithme un peu surprenant. Tout d'abord, il effectue 5 millions de md5 sur la clé, puis extrait les 5 premiers caractères du résultat, et les passe en majuscule. La clé de 5 caractères ainsi obtenue est ensuite utilisée pour décoder le message chiffré en appliquant un xor sur chaque groupe de 5 caractères. Le message décodé est alors exécuté : il s'agit donc de code python.

Comment décoder ? Notre première idée a été d'utiliser la première partie non alphanumérique du fichier « packed », avant le PDF, pour essayer de voir si cela ne serait pas la clé… Trop simple, échec !

La deuxième approche fut de programmer une attaque brute force sur les 5 caractères de la clé. Avec 20000 tentatives seulement par seconde sur notre ordinateur, ce brute force aurait pris presque une année : cela n'est bien sûr pas compatible avec les 48h du challenge ...

La troisième approche fut la bonne : l'utilisation d'un simple xor comme technique de chiffrement est extrêmement faible, chacun des 5 caractères de la clé est appliqué indépendamment des autres. On peut donc déterminer les 5 caractères un à un en réalisant cinq attaques par force brute (seulement 256 valeurs à tester pour chaque caractère !). Comme on sait que le message décodé doit contenir du code python, il est simple de déterminer pour chaque caractère laquelle des 256 valeurs est la bonne en vérifiant que la partie du message qu'il chiffre se compose de caractères alphanumériques et de ponctuation.

Une fois décodé, le message contenait le code python ci-dessous :

import sys
print "Key 2 = leetspeak(what do you call a file that is several file types at once)?"
if len(sys.argv) > 2:
    if hash(sys.argv[2])%2**32 == 2824849251:
        print "Coooooooool. Your flag is argv2(i.e. key2) concat _3peQKyRHBjsZ0TNpu"
else:
    print "argv2/key2 is missing"

Et voilà que le code contient encore une nouvelle énigme : « what do you call a file that is several file types at once ».

Un indice posté sur le site évoquait un animal qui change de couleur.

Nous avons pensé au caméléon.

Après quelques essais, nous avons trouvé que le flag était « ch4m3l30n_3peQKyRHBjsZ0TNpu ».

6. « Pay TV » : attaque d'un site Internet

Un site Internet présente une image de robots regardant une télévision « cryptée ». La télévision en elle-même comporte une image GIF animée qui imite un brouillage noir et blanc. En bas à gauche de l'image est présentée une fenêtre de saisie « password ». Bien entendu, l'entrée d'un mot de passe permettra sans doute d'afficher une image lisible sur la télévision, image qui contiendra – nous l'espérons - le jeton de validation du challenge.

capture4-s

Figure 4

Notre première idée fut d'analyser le contenu de l'image GIF animée, en espérant y trouver le mot de passe. La GIF animée comporte 6 images. Nous avons manipulé sous GIMP les différentes images, en les superposant, ou en effectuant des opérations de type xor. Sans succès.

Le site cachait deux indices qui nous ont aiguillés vers la solution.

Tout d'abord, un journal est posé à côté de la télévision. Il comporte l'indication « Side channel attacks », cf. la figure ci-jointe remise à l'endroit.

capture5-s

Figure 5

Ensuite, en étudiant les sources JavaScript du site, nous avons remarqué un commentaire très intéressant dans le code qui construit la requête pour envoyer un mot de passe :

xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
xhr.send('key=' + encodeURIComponent(key)/* + '&debug'*/)

Ainsi donc, il serait possible d'activer un mode debug ?

Alors qu'une requête normale envoyant un mot de passe erroné obtient une réponse JSON comme celle-ci :

{"response": "Wrong key.", "success": false}

En activant le mode debug, on reçoit une réponse comme celle-là :

{"start": 1382498116.458821, "end": 1382498116.458859, "response": "Wrong key.", "success": false}

Nous avons tout de suite compris que ces deux valeurs start et end étaient des estampilles temporelles (en secondes depuis l'epoch Unix) qui nous permettaient d'obtenir la durée de traitement de la requête. 

Nous avons supposé que le temps de traitement de chaque caractère du mot de passe pourrait être différent selon que le caractère soit correct ou pas. Il serait dès lors possible de trouver le mot de passe caractère par caractère.

Nous avons écrit un script qui affiche le temps de traitement de tous les mots de passe longs d'un seul caractère (en se limitant aux caractères alphanumériques) :

#! perl

use JSON;
use LWP::UserAgent;
use LWP::Protocol::https;$ENV{'PERL_LWP_SSL_VERIFY_HOSTNAME'} = 0;

my $ua = LWP::UserAgent->new;
my $url = 'https://ctf.fluxfingers.net:1316/gimmetv';
foreach my $char (0..9,'a'..'z','A'..'Z') {
    my $pw_candidate = "$char";    
    my $response = $ua->post($url, 'Content-Type' => 'application/x-www-form-urlencoded',                      'Content' => "key=${pw_candidate}&debug");    
    my $resp_content = $response->content;    
    my $json_obj = decode_json($resp_content);    
    my $duration = $json_obj->{'end'} - $json_obj->{'start'};    
    print "$pw_candidate: $duration\n";

    if($json_obj->{'success'} eq 'true') {
        print "Password found !!\n";
        print "Response: $resp_content\n";
        exit;
    }
}

Nous avons constaté que le temps de traitement était négligeable pour tous les caractères, sauf pour le « A » qui durait environ 0.1s. Nous avons donc pensé que ce devait être le premier caractère du mot de passe.

Nous avons modifié notre script pour tester cette fois tous les mots de passe longs de deux caractères dont le premier caractère est « A » :

[...]
    my $pw_candidat = "A$char";
[...]

Cette fois encore, un des mots de passe testés avait une durée de traitement plus longue de 0.1s que les autres.

Nous avons itéré ce procédé, et lorsque nous eûmes enfin trouvé le mot de passe dans son intégralité, la réponse JSON contenait :

{"response": "OH_THAT_ARTWORK!", "success": true}

La chaîne OH_THAT_ARTWORK! s'affichait sur l'écran de télévision des robots, une fois le mot de passe trouvé, et c'était bien la solution du challenge.

Conclusion

Cet article a présenté la résolution de certaines épreuves du CTF de Hack.Lu 2013. Notre modeste équipe nommée PicOwn de 3 personnes a terminé classée 6ème en local (et donc, elle est dans le Hall of Fame!) et 97ème en tout (sur plus de 700 équipes engagées).

Merci aux organisateurs qui ont proposé 21 épreuves très bien pensées et variées, parfois vraiment difficiles, surtout en cryptographie qui était pourtant un de nos thèmes de prédilection.

Les CTF de Hack.lu des quatre dernières années sont accessibles en ligne [2] et nous vous invitons à vous y frotter et, pourquoi pas, à participer à la prochaine édition, localement ou à distance !

D'autres « writeups » de ce CTF sont également disponibles en ligne [5].

Remerciements. Merci à notre relecteur de PollyPocket... et félicitations pour leur score !

capture6-s 0

Figure 6

Références

[1] Hack.lu : http://2013.hack.lu/

[2] Archives des CTF de Hack.lu : https://ctf.fluxfingers.net/

[3] http://articles.forensicfocus.com/2011/11/18/android-forensics-study-of-password-and-pattern-lock-protection/

[4] Android Hash to Gesture : https://barney.0x539.se/android/

[5] Writeups CTF Hack.lu 2013 : https://ctftime.org/event/97/tasks/



Article rédigé par

Par le(s) même(s) auteur(s)

Utilisation malveillante de l’API d’accessibilité sur Android

Magazine
Marque
MISC
Numéro
122
Mois de parution
juillet 2022
Spécialité(s)
Résumé

Destinée à faciliter la vie des utilisateurs présentant un handicap, l’API d’accessibilité d’Android a vite été détournée par des applications malveillantes comme une façon pratique de modifier l’interface utilisateur et d’interagir… sans le consentement de ce dernier. Dans cet article, nous allons parler d’un malware appelé Android/BianLian.

Piloter sa cafetière connectée

Magazine
Marque
Hackable
Numéro
33
Mois de parution
avril 2020
Spécialité(s)
Résumé

Quand j’ai acheté ma cafetière connectée, j’ai trouvé qu’elle ne faisait pas tout ce que je voulais. Les objets connectés commerciaux étant rarement libres et/ou ouverts, rien n’était prévu pour l’améliorer ou tout simplement, la configurer à ma façon. J’ai alors décidé de mettre le nez dans le café.

Les derniers articles Premiums

Les derniers articles Premium

Quarkus : applications Java pour conteneurs

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Initié par Red Hat, il y a quelques années le projet Quarkus a pris son envol et en est désormais à sa troisième version majeure. Il propose un cadre d’exécution pour une application de Java radicalement différente, où son exécution ultra optimisée en fait un parfait candidat pour le déploiement sur des conteneurs tels que ceux de Docker ou Podman. Quarkus va même encore plus loin, en permettant de transformer l’application Java en un exécutable natif ! Voici une rapide introduction, par la pratique, à cet incroyable framework, qui nous offrira l’opportunité d’illustrer également sa facilité de prise en main.

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Les listes de lecture

11 article(s) - ajoutée le 01/07/2020
Clé de voûte d'une infrastructure Windows, Active Directory est l'une des cibles les plus appréciées des attaquants. Les articles regroupés dans cette liste vous permettront de découvrir l'état de la menace, les attaques et, bien sûr, les contre-mesures.
8 article(s) - ajoutée le 13/10/2020
Découvrez les méthodologies d'analyse de la sécurité des terminaux mobiles au travers d'exemples concrets sur Android et iOS.
10 article(s) - ajoutée le 13/10/2020
Vous retrouverez ici un ensemble d'articles sur les usages contemporains de la cryptographie (whitebox, courbes elliptiques, embarqué, post-quantique), qu'il s'agisse de rechercher des vulnérabilités ou simplement comprendre les fondamentaux du domaine.
Voir les 66 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous