e-m-b-a / emba

EMBA - The firmware security analyzer

Home Page:https://www.securefirmware.de

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

False positive confirmed exploit if embedded device has a telnet port (exploit/linux/telnet/netgear_telnetenable)

floyd-fuh opened this issue · comments

Describe the bug
The following metasploit module shows as a verified exploit but is a false positive when the embedded devices runs a telnet daemon: netgear_telnetenable

To Reproduce
Steps to reproduce the behavior:

  1. EMBA installation (default mode)
  2. Use the firmware available here: EDS-MD_8_4_0_0R1.rom
  3. Start EMBA with the following parameters: sudo ./emba.sh -f ./EDS-MD_8_4_0_0R1.rom -l ./lantronix -W -t -E -Q
  4. You will see that "exploit/linux/telnet/netgear_telnetenable.md" is a confirmed exploit, but this is just a false positive. Although you get a "shell" from the exploit, it's just an unauthenticated telnet session to the telnet daemon (so basically nothing was exploited, you could also just netcat to the telnet port to get the same result)

Expected behavior
Should not be shown as a verified exploit.

Desktop (please complete the following information):

  • OS: Kali Linux
  • EMBA version: current master branch
  • Installation method: default with up to date docker image

Priority issue
Are you already a [Sponsor]? - [Y/N]
N

Additional context
You can't "really" fix it as long as you just check "opened shells", except excluding that metasploit module. It will be a false positive for devices that have a telnet port I assume (not tested, but from the metasploit module code it looks like it). The metasploit module is not very clever, it basically sends a magic packet to the port (which is just ignored) and then opens a connect shell. Of course that connect shell opens, because it's a telnet daemon. But it's still unauthenticated, so the exploit didn't really "open" a telnet root shell, it just connected to the already present telnetd. What you could do is run the exploit only if you find "netgear" in the firmware strings, which is probably a pretty good trade-off.

What you could do is run the exploit only if you find "netgear" in the firmware strings, which is probably a pretty good trade-off.

This solution looks for me like a pretty good tradeoff