Ein Telnet-Wurm beutet die Sicherheitslücke (VU#881872) vom Sun "Solaris" Telnet daemon (in.telnetd) aus.

By: Florin Caministeanu

Eine Sicherheitslücke in den Sun "Solaris" Telnet daemon einschalten sehr einfach für Viren und Hackers in diesen Systemen Eingang zu finden. Betroffene

Systeme sind Sun "Solaris" 10 (SunOS 5.10) und Sun "Nevada" (SunOS 5.11). Betroffene Architekturen sind beide SPARC und Intel-(x86). Mindestens ein Wurm wird bisher als gewusst, diese Sicherheitslücke zu benützen, um Systemintegrität zu gefährden. Und das kann nur spitze des Eisbergs sein...

Die Sicherheitslücke VU#881872 Notiz

I. Was kann es passiert?

Das Sun Microsystems hat eine Sicherheitslücke im Sun "Solaris" Telnet daemon (in.telentd) angekündigt. Diese Sicherheitsanfälligkeit kann, für einem lokalen oder entfernten unprivileged-Benutzer, eine Anbindung mit dem Host herstellen, wenn Telnet(1) Dienstleistung benutzt ist (auf TCP Port 23). Der Benutzer erwirbt den unbefugten Zugang zu diesem Host, wenn er als jeder Benutzer auf dem System verbindet. Dies erlaubt zu dem Angreifer, um willkürliche Befehle mit den Privilegien dieses Benutzers auszuführen. Dies würde den Root-Benutzer (uid 0) beinhalten, wenn der Hoster konfiguriert wird, um Telnet als der Root-Benutzer Anmeldungen zu akzeptieren. Mindestens ein Wurm wird bisher als gewusst, diese Sicherheitslücke zu benützen, um Systemintegrität zu gefährden.

II. Ist mein System beeinflusst?

Diese Sicherheitslücke kann in den folgenden Systemfreigabe vorkommen:
SPARC Architekturen;

Solaris 10 ohne die Korrektur 120068-02;
x86 Architekturen;

Solaris 10 ohne die Korrektur 120069-02.

Solaris 8 und 9 sind nicht von dieser Sicherheitslücke beeinflusst.

Diese Ausgabe beeinflusst Systeme nur, die die Telnet(1) Dienstleistung ermöglichen lassen. Der folgende Befehl kann benutzt werden, um zu entscheiden, wenn die Dienstleistung ermöglicht wird. Für die Dienstleistungszustand die Ausgabe "online" vorkommen, wenn das System beeinflusst wird:
    $ svcs telnet
    STATE          STIME    FMRI
    online         Jan_30   svc:/network/telnet:default

Wenn entfernte Root-Logins arbeitsunfähig sind, wird der Root-Benutzer von der Wirkung dieser Sicherheitslücke nicht beeinflusst. Entfernte Root-Logins sind gesperrt, wenn die Datei "/etc/default/login" eine Reihe enthält, die mit "CONSOLE" beginnt. Dies kann gesehen werden bei Benützung des grep Befehls, wie gezeigt wird unter:

    $ grep CONSOLE /etc/default/login
    CONSOLE=/dev/console

Wenn diese Reihe mit "#" kommentiert ist, oder wenn diese Reihe nicht da ist, dann wird der Root-Benutzer auch beeinflusst.
    #CONSOLE=/dev/console

Je nach der Weise in dieser Sicherheitslücke wurde ausgebeutet, kann die Ausgabe von Befehlen wie last(1) (der die Informationen über die An- und Abmeldungsaktivität ausstellt) unerwartete Anmeldungen zum System zeigen. Die Benützung die "-a" Fahne mit dem last(1) Befehl, wird den Hostname zeigen, das ist mit diesen Anmeldungen verbunden.

III. Was kann ich tun?

Zu workaround diese Ausgabe kann die Telnet Dienstleistung, als in dem folgenden Beispiel, arbeitsunfähig sein (Anmerkung, die dies entfernen wird, die Funktionalität vom in.telnetd daemon auf diesem Hoster):
    # svcadm disable svc:/network/telnet:default

Außerdem ist es auch möglich in die Datei "/etc/default/login" die Reihe, die mit CONSOLE beginnt, unkommentiert oder hinzufügt, wie unten:
    CONSOLE=/dev/console

Dies wird allerdings den unbefugten Zugang zum Root-Benutzer nur verhindern; andere Benutzerkonten werden noch von dieser Ausgabe beeinflusst.

Benutzen Sie ein Firewall oder eine andere Datenpaket-Filtern Technologie, wie ipfilter, das mit Solaris 10 versandt wird, um das entsprechende Ports zu sperren. Befragen Ihr Verkäufer oder Ihre Firewall Dokumentation für detaillierte Anweisungen dazu, wie man der Port konfiguriert.

Verwendung SSH statt Telnet. SSH ist sicherer als Telnet. Als allgemeiner Rat empfehlen wir, SSH eher als Telnet zu benutzen.

Aktualisieren zu Korrekturen 120068-02 oder 120069-02, abhängig von Ihrem System. Diese Korrekturen finden Sie unter

http://sunsolve.sun.com/search/document.do?assetkey=urn:cds:docid:1-21-120068-02-1

und

http://sunsolve.sun.com/search/document.do?assetkey=urn:cds:docid:1-21-120069-02-1.

Nach der Korrekturinstallierung, ist ein System Reboot NICHT notwendig.

Der Telnet-Wurm

I. Bekannte Wurm Aktivität.

Die Charakteristika des Wurms umfassen, aber sind nicht beschränkt auf:

1) Ausbeuten VU#881872 um via Telnet als adm oder lp Benutzer anzumelden;
2) Verändern Zulassungen auf "/var/adm/wtmpx" zu "-rw-R--rw-";
3) Schaffen das Inhaltsverzeichnis ".amd" in "/var/adm/sa/";
4) Hinzufügen ".profile" Dateien zu "/var/adm/" und "/var/spool/lp/";
5) Installieren einer authentisierten Backdoor-shell auf TCP Port 32982;
6) Modifizieren crontab-Eintritte für adm und lp Benutzer;
7) Abfragen für anderen Hoster, die (TCP Port 23) Telnet laufen lassen.

II. Wie kann ich sehen ob mein System von Telnet-Wurm beeinflusst ist?

Hier sind ein paar Schritte, um zu helfen, zu entscheiden, wenn ein Solaris 10 oder Nevada-System infiziert sein kann: 

     $ ls -la /var/adm/wtmpx
Wenn die Erlaubnisse sind:
     -rw-r--rw-   1 adm      adm         1116 Feb 28 12:03 wtmpx
das System kann infiziert sein.

Danach, der folgende Befehl kann laufen gelassen werden:

     $ ls -la /var/adm/sa
Wenn es ein Inhaltsverzeichnis gibt das genannt wird ".adm", dann ist das System wahrscheinlich infiziert. Andere mögliche Anzeigen umfassen die Existenz der Dateien:
     /var/adm/.profile
     /var/spool/lp/.profile

Zusätzlich mögliche Anzeigen umfassen modifizierte crontab Eintritte für "adm" und "lp" Benutzer:
     # cd /var/spool/cron/crontabs
     # grep PATH=\. *
     adm:#10 1 * * * (cd /var/adm/sa/ && cd .adm && [ -x sysadm ] && PATH=.  sysadm) >/dev/null 2>&1 &
     lp:#10 1 * * * (cd /var/spool/lp/admins/ && cd .lp && [ -x lpsystem ] && PATH=. lpsystem) >/dev/null 2>&1 &

III. Schutz

Das folgende Korn-Shell Skript "inoculate.local" kann vor Ort auf einem infizierten System laufen, um den Wurm zu entfernen und verhindern weiteres re-infection wenn man die Telnet Dienstleistung sperrt. Kopieren das Skript in eine Datei (zum Beispiel in "/tmp" oder "/var/tmp") und laufen das Skript als der Root-Benutzer:

#!/bin/ksh -p
#
# Save this script as "inoculate.local" (for example, in /tmp or /var/tmp) and
# run the script as the root user
#
# Usage: inoculate.local

/usr/sbin/svcadm disable telnet || {
        echo This script must run as root. 1>&2
        exit 1
}

# Cleanup filesystem
/bin/rm -f /var/adm/.profile /var/spool/lp/.profile
/bin/rm -rf /var/spool/lp/admins/.lp
/bin/rm -rf /var/adm/sa/.adm
/bin/chmod 644 /var/adm/wtmpx

# Cleanup crontab
t=`/bin/mktemp /tmp/cr.XXXXXX`

/bin/crontab -l adm > $t
/bin/egrep -v 'Restarting scheduler|cd \.adm' $t | su adm -c /bin/crontab

/bin/crontab -l lp > $t
/bin/egrep -v 'Restarting scheduler|cd \.lp' $t | su lp -c /bin/crontab

/bin/rm -f $t

# Kill processes
/bin/pkill -9 -u lp 'lpshut|lpsystem|lpadmin|lpmove|lpusers|lpfilter|lpstat|lpd|lpsched|lpc'
/bin/pkill -9 -u adm

'devfsadmd|svcadm|cfgadm|kadmind|zoneadmd|sadm|sysadm|dladm|bootadm|routeadm|uadmin|acctadm|cryptoadm|inetadm|logadm|nlsadmin|sacadm|syseventadmd|ttyadmd|con

sadmd|metadevadm'

Ein System Reboot ist NICHT notwendig.

---