Bitmessage/Soucis : Différence entre versions

De WikiOpenTruc
Aller à : navigation, rechercher
m (→‎Attaque du 13/02/2018)
(→‎IPs en clair dans le code source)
 
(2 révisions intermédiaires par un autre utilisateur non affichées)
Ligne 5 : Ligne 5 :
 
Mais là, cerise sur le gâteau, c'est le logiciel sensé être utile qui est lui-même le vecteur de l'attaque.
 
Mais là, cerise sur le gâteau, c'est le logiciel sensé être utile qui est lui-même le vecteur de l'attaque.
  
−
Et la faille exploitée serait là depuis 15 mois.
+
Et la faille exploitée serait là depuis 15 mois. <i>since Nov 14, 2016 when support for receiving extended encoding messages was enabled.</i>
−
Ouverte pour autoriser des niaiseries (emojis etc).
 
  
 
Semblait surtout viser les machines windows.
 
Semblait surtout viser les machines windows.
Ligne 175 : Ligne 174 :
 
<br>
 
<br>
  
−
==Pages connexes==
+
[[Catégorie:internet]]
−
 
 
−
* [[Bitmessage/Contribute]]
 
−
 
 
−
<br>
 

Version actuelle datée du 20 juillet 2019 à 18:59

Attaque du 13/02/2018

Il ne s'agit pas simplement d'un dysfonctionnement (ce qui est monnaie courante). Mais là, cerise sur le gâteau, c'est le logiciel sensé être utile qui est lui-même le vecteur de l'attaque.

Et la faille exploitée serait là depuis 15 mois. since Nov 14, 2016 when support for receiving extended encoding messages was enabled.

Semblait surtout viser les machines windows. mais, ça révèle d'assez grosses failles dans le code, des précautions assez classiques qui n'ont pas été prises. Des choses autorisées sans faire de vrai bilan entre l'intérêt (quasi-nul) et les risques avérés aujourd'hui.

Ce sont un ou des portefeuilles cryptos qui étaient visés :
On my computer, the attacker appeared to focus on finding bitcoin wallets (electrum, multibit, bitcoin core), credit card details, firefox passwords, other passwords, private gpg keys. Maybe ssh keys and client ssl certificates, this isn't entirely clear to me ...

Certains suspectent même des zerodays volontairement introduites par les devs ... ça craint:
What is reason for anything that could evaluate injected code to be in the implementation? We're dealing with text messages. Why do PyBitmessage need to evaluate anything in messages? Why is eval doing anything with message data?

I suggest gutting all pickle, eval, compile, and exec statements from both the bitmessage and PyBitmessage QT GUI codebases. Replace them with conversion of all transitory values and objects to mathematical operators or base64 text, denying any attack surface for injection from any vector. Any module in python that has eval, pickle, compile, exec or similar execution features should either be gutted removing those features from the codebase, or an entirely new library templated off it without the offending features. Look at it this way. Treat it according to the old Unix philosophy or Plan9: Everything is text, everything is a file, and only alter text or files, don't let code write itself. Treat all sockets and connections as files/text, read only as values, not iterable, not alterable by any of their own parameters. All alteration parameters must come from within the program, with each type of data alteration separated into its own logical sphere, and only internal logic can bridge those spheres. On most linux distros firejail is available and is very secure. The bitmessage startup script should look for firejail and attempt to invoke / install it first. Bitmessage can also be set to install itself in a new chroot, then set itself up in a virtualenv in the chroot, on first run, then invoke firejail on that virtualenv. At the protocol level, variables / dicts holding keys should be walled off from the program by intermediary functions that check the authority of source and destination in all movement of key values. Once keys are loaded into memory, that part of the program should be removed from memory, and no further access to keys.dat without passing through a cop function. The keys.dat and messages.dat should be encrypted on disk, and an option for a passphrase to start bitmessage and decrypt those files for the program. These measures will approach bulletproof on linux, and you don't have to mess around with selinux policies and apparmor. There are many more things that can be done, but this would be a good start.

Il faut lire le chan bitmessage. L'attaque pourrait même être due à la NSA (ou un truc du genre), cherchant à nuire aux détenteurs/mainteneurs de noeuds : connaître leurs comptes cryptos, etc. et à nuire par contrecoup au projet global. ... ça va probablement refroidir pas mal de participants, voire globalement bien freiner le projet, ou pire.

La confiance dans les devs est quand même pas mal atteinte. Surtout que les remarques quant aux vulnérabilités ne datent pas d'hier, et n'ont débouché sur aucun correctif sérieux du codebase.

Perso, c'est la manière dont le wiki est verrouillé qui m'inquiète. Qu'on ne laisse pas 100 personnes intervenir, c'est compréhensible. Que seuls 3 pseudos puissent éditer, alors qu'il y a/avait une bonne dizaine d'autres participants compétents, ça ne me parait pas très bien.

Correctifs / précautions :

  • firejail,
  • archivage quotidien par cron,
  • noyer ce qui compte dans des centaines de GB de fake data
  • torchat


NB : Ma machine remote, sous Debian, ne montre aucune trace d'attaque. C'est une illustration de l'intérêt (et même la nécessité impérieuse) de faire tourner ces programmes/noeuds de manière cloisonnée, sur des machines qui ne font que ça, et où il n'y a rien d'autre.
Un point comique, est qu'un paquet de participants au projet discutent totalement anonymement sur le chan bimessage (même pas de pseudo), ce qui ne facilite vraiment pas les échanges. Et autres précautions "virtue signalling" à la con ... et à coté de ça, certains de ces devs font tourner leur bitmessage sur leur machine perso ...


Communauté

... c'est un peu le bronx. :-(

Et à la lumière de l'attaque du 13/02/2018, ça peut/doit interpeller.

Bitmessage est un projet a priori sympathique, mais in fine, le fait pour un projet de ce genre, au bout de plusieurs années, de ne pas être backé par au moins une grande association dont c'est l'objet, eg EFF ou dans le genre, ça n'est probablement pas tout à fait un hasard. ça signifie que :

  • pendant tout ce temps, personne dans ces assocs (et pourtant il y a des gens compétents) n'a accroché sur le projet,
  • en pratique, ces assocs fournissent 0 manpower en soutien et en audit.

Bref, le critère communauté est important, si pas primordial.


Scalabilité

Si je comprends bien, la prise en compte de ce souci devrait être gérée par les streams. La GUI 2018 affiche déjà le stream 1, et a priori il n'y a pas encore de stream 2, donc on ne sait pas vraiment si l'implémentation actuelle fonctionnerait réellement.


Forward du port 8444

  • a yellow light would mean that you only have outgoing connections, but no incoming.
    • ce qui signifie aussi que BM fonctionne uniquement en mode client, ie n'est de facto pas un noeud
  • you may have to configure port-forwarding on your router, to forward port 8444 from wan to port 8444 on the computer running the bitmessage-client.
  • J'ai paramétré le routeur censément comme il faut pour le port 8444 (et uniquement celui-là), http://www.portchecktool.com/ me dit cependant :
    • Problem! I could not see your service on monip on port (8444). Reason: Connection timed out.
    • Problem! I could not see your service on monip on port (8555). Reason: Connection timed out.
    • a priori, cela semble signifier que le paramétrage du routeur pour le port 8444 est sans effet ?



cela expliquerait peut-être aussi :

  • pourquoi, quasi systématiquement, le nombre de connexions BM monte au lancement ... puis décroit doucement jusqu'à 0, alors même que le fichier knownnodes.dat ne cesse de grossir.
  • les soucis analogues avec transmission/bitorrent
  • bref -> voir : VPS ou autres soluces en remote


  • à noter que, après avoir réalisé le forward du port 8444 sur le routeur, cela n'apparaît pas sur le RPI avec netstat -a. Je dois lancer le service (ie python bitmessagemain.py) pour que les lignes suivantes apparaissent :
# netstat -a | grep 8444
tcp        0      0 0.0.0.0:8444            0.0.0.0:*               LISTEN     
...
udp        0      0 0.0.0.0:8444            0.0.0.0:*

... de fait, c'est le lancement de BM qui provoque l'affichage de ces lignes, et lui seul.


  • est-ce que les ports sont fermés par défaut sur raspberry ?
    • j'ai lu qq part que Debian/raspbian ferme par défaut les ports < 1000.




Fausse piste :


Mode portable

Je fais tourner BM sur clé USB. Et j'ai bien coché le mode portable dans les paramètres. Tous les fichiers de travail vont bien dans /PyBitmessage/src, sauf pybitmessage.conf qui persiste à rester dans ~/.config/pybitmessage



Messages au lancement

  • Gtk-Message: Failed to load module "canberra-gtk-module"
    • dans mon cas libcanberra-gtk3-module est installé, mais pas libcanberra-gtk-module
    • a priori, il faut donc installer libcanberra-gtk-module soit via apt-get install soit via synaptic
    • NB : c'est un petit paquet


IPs en clair dans le code source

  • il y a des IPs en clair dans le code source, dans src/defaultKnownNodes.py. a priori il s'agirait des noeuds de bootstrap. Un attaquant du réseau Bitmessage pourrait cibler ces IPs (attaque DoS ou autre).
  • NB : Les IPs 2017 ne sont pas les mêmes qu'en 2013.
  • on ne peut pas exclure que (certaines de) ces IPs soient des honey pots ? Et/ou des canaris.
  • Il faut noter que ces noeuds de bootstrap ne servent normalement qu'une seule fois, lors du 1° lancement de bitmessage. Dès ce 1° lancement, un fichier knownnodes.dat est créé et copieusement garni, et c'est lui qui fournira des noeuds. Ce fichier peut aussi s'échanger entre mainteneurs.

There are three mechanisms Bitmessage uses to learn of nodes.

1. about 10 are hardcoded. These are only used when you run the client the first time or when you delete your knownNodes.dat file.

2. DNS bootstrapping. On startup, Bitmessage looks up the DNS A-records for bootstrap8080.bitmessage.org and bootstrap8444.bitmessage.org and adds those to its list. This is very much like method #1 except that I don't have to update the source code to update the list of peers.

3. After the client is connected to another peer, peers share nodes using addr messages. This is continuously updated. At this point the first two methods really aren't important at all; the knownNodes list will grow plenty big using this third method. (Max 20K peers in the list).

If your client doesn't hear that a peer is active and cannot connect to it for two days then it removes it from the list until you have less than 1000 peers in your list at which point it stops removing them.


Récupérée de « https://opentruc.fr/w/index.php?title=Bitmessage/Soucis&oldid=14259 »