You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to highlight a security issue in RaspberryJuice. As you know, the external connection with the plugin on port 4711 is unauthentication/unencrypted thus the traffic can be disclosed and even manipulated
Below is traffic from a third machine eavesdrop on a client connected to RaspberryJuice using ettercap:
tcpdump -A -i eth1 port 4711 and host 192.168.56.110
04:05:09.845686 IP 192.168.56.110.39210 > 192.168.56.103.4711: Flags [P.], seq 1:28, ack 1, win 229, options [nop,nop,TS val 1057102917 ecr 39383616], length 27
E..O.@@.@..B..8n..8g.*.g@.C._@.............
?..E.X.@chat.post(Hello Minecraft)
Manipulating the data is also possible, with proper ettercap filter, the client try again send his message but it was altered with the third party on the road:
Suggestions to prevent this:
I think adding a hostname in the config is not enough especially when the server owner wants to allow his server for his LAN. So providing a security option in config.yml to use TLS with cipher like RSA, DH, ECDH for keys exchanges would be suffecint.
The text was updated successfully, but these errors were encountered:
Hi,
I would like to highlight a security issue in RaspberryJuice. As you know, the external connection with the plugin on port 4711 is unauthentication/unencrypted thus the traffic can be disclosed and even manipulated
Below is traffic from a third machine eavesdrop on a client connected to RaspberryJuice using ettercap:
Manipulating the data is also possible, with proper ettercap filter, the client try again send his message but it was altered with the third party on the road:
Suggestions to prevent this:
I think adding a hostname in the config is not enough especially when the server owner wants to allow his server for his LAN. So providing a security option in config.yml to use TLS with cipher like RSA, DH, ECDH for keys exchanges would be suffecint.
The text was updated successfully, but these errors were encountered: