Amnesia:33 : 33 failles qui impactent « des millions d’objets connectés »

Amnesia:33 : 33 failles qui impactent « des millions d’objets connectés »

Par Sébastien Gavois

Le 10 Décembre 2020 à 07h48
Sciences et espace
1 min 8

Amnesia:33 : 33 failles qui impactent « des millions d’objets connectés »

Découvertes par Forescout Research Labs, elles concernent « quatre stacks TCP / IP open source (uIP, FNET, picoTCP et Nut / Net), qui servent collectivement de composants de bases à des millions d'appareils connectés dans le monde ».

Les risques sont importants selon les chercheurs : « Ces vulnérabilités provoquent principalement une corruption de la mémoire, permettant aux attaquants de compromettre les appareils, d'exécuter du code malveillant, de lancer des attaques par déni de service et de dérober des informations sensibles ».

Une vidéo de présentation, des explications et des documents techniques ont été mis en ligne par ici.

Commentaires (8)


tiret
Le 10/12/2020 à 08h02

D’un autre côté peu d’objets connectés sont vraiment utiles car ils dépendent précisément d’un serveur que l’utilisateur ne maîtrise pas. Et quand le serveur est coupé…


TexMex
Le 10/12/2020 à 11h18

Enfin!
Non seulement c’est beau car on fera fermer sa gueule à un tas




  • De loufoque qui répondent “tu es fou ca n’arrivera jamais”, “c’est sécure” quand on leur dit de faire attention.

  • De programmeurs à la con qui prétend à la quintessence sans pour autant comprendre ce qu’il fait.

  • D’aficionado de l’open source et du libre (sans comprendre la différence) qui ne voient pas la déliquescence des librairies tout en disant que c’est un environnement “dynamique”…



Haaaaa c’est beau.


Zone démilitarisée Abonné
Le 10/12/2020 à 13h32

Les objets connectés, c’est un pacte avec le diable.


Winderly Abonné
Le 10/12/2020 à 16h13

TexMex a dit:


…D’aficionado de l’open source et du libre (sans comprendre la différence) qui ne voient pas la déliquescence des librairies tout en disant que c’est un environnement “dynamique”…




Les objets connectés utilisant des libraires concurrentes et/ou propriétaires seraient plus sécure ? Vraie question.


TexMex
Le 10/12/2020 à 18h14

Winderly a dit:


Les objets connectés utilisant des libraires concurrentes et/ou propriétaires seraient plus sécure ? Vraie question.




TL:DR
Le problème; ce n’est pas les librairies ce sont les gens. Plusieurs constats depuis des décades. Cela n’est pas seulement valable pour l’IOT. Hélas non.





Le code officiel (ou estampillé) a une tendance à stagner (ex kernel windows) et surtout à ne plus être soumis à des audits réguliers.
Conséquence:




  • Potentielle faille vielle de 30 piges (ex : scp )

  • Ne suit pas très bien les évolutions. Seul résistent les “atomes” dans le sens ou on ne peut pas descendre plus bas (ex: ls ) et les plus simple.



Le code ‘communautaire’ a une tendance à bouger (trop?)
Conséquence




  • Potentiel problème comme celui d’un module NPM repris puis “détourné” pour en faire un “farmer à bitcoin”. Sinon pire.

  • Obsolescence/changement rapide (ex react-native-camera vs expo-camera) et tout le monde ne suit pas. Ce qui amène à une panoplie d’applications jetables et donc force à réinventer la soupe constament (ou trouver des contournement à ces changements pénalisant). En plus cela produit les mêmes cycles de maturation avec évidement ses problèmes de sécurité. Ce qui bien entendu sont les grosses tâches dans le décor quand on essaie de faire un truc intelligent.



Et pour autant on n’a toujours les mêmes arguments débiles du genre: L’open source tout le monde peut relire le code”. Sauf qu’il n’y a pas grand monde qui le fait ou que personne ne le certifie. C’est à dire que seules des boites qui font de l’audit sécurité vont le faire pour leurs clients ou en mode “chasseur de prime”. Nulle part je ne lis qu’un module NPM (ou d’une autre crèmerie) a été certifié comme sûr par un X ou Y. Aucune de ces crèmeries n’a intérêt à en parler. On joue plutôt à étouffer les affaires.



L’incident cité plus haut nous a montré que c’est bel et bien un vaste foutage de gueule. Virer un module ne permet pas de garantir la sécurité des autres modules. Plouf… Et encore moins de mettre des systèmes en place pour travailler sur le sujet. Pour ça il faut embaucher du monde… Ça coûte un peu.



Bref dans les deux mouture de code c’est simplement une expression du même problème humain : flemme, coder avec les pied pour avant hier, suivi, maintenance, libre (sans garantie) etc. Et éventuellement trouver les failles via des moyens nouveaux.



Il est évident qu’il faudrait un organe permettant de s’occuper du sujet.
Voyons qui:




  • Les entreprises… compte pas la dessus. Elles ne veulent pas s’en occuper pour simplement ne jamais avoir à admettre qu’une des libs qu’elle utilisent sont foireuses et que donc leur produit aussi. Et puis dans ce cas les assureurs s’invitent dans les réunions.

  • Les communautaires… pareil. Mais sans le pognon qui évidement leur fait souvent défaut. et on peut leur ajouter le 3eme point qui suit.

  • Les individus… Problème de certification et de confiance. Qui dit qu’on faire confiance à un gars non identifié physiquement ? Qui dit qu’il est apte ? Même s’il a envie de sauver le monde à lui tout seul (parce qu’il est “from the internets”). L’envie ne fait pas le paladin.



Le seul niveau pertinent aujourd’hui est au niveau de l’état. Non pas pour interdire mais pour au moins estampiller avec un tampon un peu comme pour l’alimentaire. Il y a des problème mais au moins permet au public d’obtenir une centralisation de l’information et si possible bien vérifiée.



Aujourd’hui si on prend github et consort on voit bien que ce qui est mis en avant par les fichiers “README” ce n’est pas la certification sécurité mais plutôt le nombre de DL et j’en passe. Y compris pour des boites comme M$.



Le seul moment ou elles s’en occupent c’est parce que cela les menace directement. Autrement le bulletin de GitHub on ne le voit jamais. Et encore c’est plus pour te dire que tu devrais utiliser des libs plus récentes. En gros cela ne s’appelle pas de la sécu.



Il y a bien une ou deux initiatives par ci par la. Mais rien de global permettant de couvrir efficacement les différents sujets.



Le plus triste dans cette affaire c’est que c’est le monde de l’industrie qui par ces méthodes qu’elle applique et que les communautaires copient bien souvent fait aboutir à ce genre de chose.



On en est même pas à une prise de conscience concertée.


j34n-r0x0r
Le 10/12/2020 à 20h07

Merci pour le mini pavé de rappel. :chinois:



Et n’oubliez pas la blague moins drôle que vrai :
“The s in IoT stands for security.”


wanou Abonné
Le 10/12/2020 à 20h07

Je viens de lire le livre blanc et je l’ai jeté direct:




  • Pas mal de failles concernent IPv6: ils conseillent de le bloquer ou le désactiver (quelle bande de crétins) ;

  • Pas mal de failles concernent IPv4: ils conseillent juste de surveiller les paquets mal formés.



Quitte à arrêter l’un des protocoles IP pour limiter les attaques, autant désactiver IPv4 car c’est par ce protocole qu’il y a le plus de chance de se faire attaquer:




  • Le nombre de tentatives de scan et d’attaque est considérablement plus élevé en IPv4 ;

  • Les chances de trouver une adresse IPv6 à attaquer en réseau local dès lors qu’il y a des commutateurs est considérablement plus faible qu’en IPv4 (rien qu’avec la réponse du DHCP, la recherche se réduit rapidement).


ToMMyBoaY Abonné
Le 11/12/2020 à 06h23

wanou a dit:


Je viens de lire le livre blanc et je l’ai jeté direct:




  • Pas mal de failles concernent IPv6: ils conseillent de le bloquer ou le désactiver (quelle bande de crétins) ;

  • Pas mal de failles concernent IPv4: ils conseillent juste de surveiller les paquets mal formés.



Quitte à arrêter l’un des protocoles IP pour limiter les attaques, autant désactiver IPv4 car c’est par ce protocole qu’il y a le plus de chance de se faire attaquer:




  • Le nombre de tentatives de scan et d’attaque est considérablement plus élevé en IPv4 ;

  • Les chances de trouver une adresse IPv6 à attaquer en réseau local dès lors qu’il y a des commutateurs est considérablement plus faible qu’en IPv4 (rien qu’avec la réponse du DHCP, la recherche se réduit rapidement).




:chinois:



Ce livre blanc est typique du nouveau business tournant autour des vulnérabilités. C’est juste du placement produit / publicité avec deux / trois conseils génériques.



Bien que je sois largement d’accord avec les propos de TexMex, je pense qu’il existe aujourd’hui une vraie volonté de créer du sensationnalisme autour des vulnérabilités dégradant énormément la qualité du travail de fond (Analyse d’impact, remédiation etc). Cet article est la preuve qu’on parle de Forescout un peu partout et je crains que ce soit le seul but recherché.


Fermer