Les codes-barres comme vecteur d'attaque?
Il y a quelques semaines, je regardais une vidéo Defcon où un gars montrait comment les lecteurs de codes-barres étaient généralement assez faciles à pirater. Il a poursuivi en disant que, comme la plupart des systèmes, l'entrée n'est pas nettoyée (sons similaires à l'injection SQL) et que la plupart d'entre eux étaient configurables par des codes à barres facilement obtenus par le fabricant. Combiné au fait qu'une machine peut être rapidement configurée pour lire tous les types de codes-barres, y compris ceux qui peuvent stocker plus de 1 000 caractères, les codes-barres sont-ils une vulnérabilité? Et comment pourrait-on empêcher cela?
Jusqu'à présent, les vulnérabilités possibles que je peux voir sont l'injection SQL et les débordements de tampon.
Oui, les scanners de codes à barres présentent une vulnérabilité potentielle. Vous devez empêcher les attaques de ce vecteur de la même manière que vous empêcheriez les attaques de tout vecteur d'entrée, comme une connexion réseau ou un clavier.
Validez les entrées dans l'application, pas le scanner. Ne vous fiez pas à la configuration du scanner pour ne délivrer que des codes-barres UPC-A à 12 chiffres. Comme chaque développeur d'applications Web l'apprend rapidement, faire confiance au client pour effectuer un nettoyage des entrées est un trou de sécurité géant. Utilisez des vérifications de longueur dans l'application pour vous assurer que les débordements de tampon ne peuvent pas être exploités. Effectuez des vérifications de liste blanche pour vous assurer que vous n'avez pas de caractères hors limites (par exemple, si vous vous attendez à ce que l'utilisateur ne numérise qu'un code-barres UPC-A ou EAN-13 de produit, vous devez lever une exception si l'entrée détecte des valeurs non numériques.)
Code défensivement. Tout comme avec une application web, vous devez faire des choix de codage sécurisés tels que SQL paramétré. Vous devriez déjà le faire pour vous protéger contre les attaques par injection SQL entrées au clavier; les codes-barres n'ont rien de spécial ici.
Renforcez vos appareils. La plupart des lecteurs de codes-barres sont initialement configurés en scannant une série de codes-barres spéciaux fournis par le fabricant (la documentation de vos scanners décrira ces symboles.) Lisez la documentation des scanners pour trouver le moyen de configurer les scanners depuis l'ordinateur hôte via la connexion de données. Une fois que vous pouvez configurer les scanners à partir de l'ordinateur, faites-le. Parmi les éléments de configuration à définir, vous devez désactiver la capacité du scanner à lire les codes-barres de configuration.
De nombreux scanners de codes à barres sont traités par le système d'exploitation comme un type de clavier. Cela leur donne exactement la même surface d'attaque que quelqu'un tapant les informations du code-barres au clavier. À titre d'exemple extrême, un lecteur de codes-barres qui comprend mode octet PDF 417 ou code QR binaire pourrait commander à l'ordinateur de quitter le courant programme, lancez Internet Explorer, téléchargez un programme à partir du site Web choisi par l'attaquant et exécutez ce programme.
Le code-barres n'est qu'une représentation de l'entrée.
les codes-barres sont-ils une vulnérabilité? pourrait s'écrire les entrées sont-elles une vulnérabilité?. En soi non, mais c'est un vecteur d'attaque.
Les codes-barres codent normalement des données numériques, sous forme de chaîne ou binaires. En plus de la façon dont ces données peuvent être utilisées pour l'exploitation à différents niveaux (vous mentionnez le débordement de la mémoire tampon, mais cela remonte dans la chaîne logicielle - les codes à barres peuvent inclure des URL qui sont interprétées par le système d'exploitation/navigateur, puis par le logiciel côté serveur), tenez également compte de l'analyse des codes-barres eux-mêmes, qui peuvent contenir des accès hors limites, des débordements, etc.
La prévention? Comme toujours, saisissez la validation d'un assainissement.
Sans validation d'entrée, tout est un vecteur d'attaque possible. J'ai même entendu parler d'un SQLI utilisant des plaques d'immatriculation comme source d'entrée. Lors de la programmation d'un radar, personne ne penserait à une idée aussi folle, et c'est le problème!