Posts Tagged ‘SSH’

Samstag, 11. September 2021

Notfallmässig eine Reverse Shell auf einem Linux-System aufbauen

Heute habe ich auf einem meiner Linux-Systems nach langer Zeit wieder einmal apt-get upgrade durchgeführt. Eines der wenigen System in meinem Fuhrpark, auf welchem noch Debian Stretch läuft.

Per SSH aus der Ferne eingeloggt, winkte ich die Meldungen durch — und musste offenbar übersehen haben, dass apt-get vor hatte, eine ganze Ladung kritischer Dienste zu entfernen. Unter anderem auch das Paket openssh-server. Nachdem das Update durch war, logge ich mich mittels Druck auf Ctrl-D aus. Und sah erst dann monits Warnmeldungen in meiner INBOX, dass auf TCP 22 kein SSH Daemon mehr lauschte. Doch dann war es bereits zu spät — ich hatte die letzte „Brücke“ zum Server soeben mit Ctrl-D in die Wüste geschickt.

Alle meine Systeme sysloggen via Site-to-Site-VPN auf einen zentralen ELK-Server. In Kibana dann die Hiobs-Botschaft:

sshd[10954]: error: rexec of /usr/sbin/sshd failed: No such file or directory

Sowie

sshd[10954]: fatal: chroot("/run/sshd"): No such file or directory [preauth]

Da der Server 13 Kilometer weit weg in der Wohnung eines Bekannten steht, hatte ich den Salat. Ich wollte eine Autofahrt vor Ort unbedingt vermeiden.

Glücklicherweise war der Bekannte gerade zu Hause und erklärte sich bereit, mir in diesem Notfall als manuelles, menschliches KVM zu helfen.

Als erstes leitete ich ihn via iMessage an, sich in den Laptop einzuloggen. Das klappte. Anschliessend wollte ich ihn zwei Befehle ausführen lassen:

$ sudo su -
# apt-get install openssh-server

Doch bereits der erste Befehl produzierte eine Fehlermeldung:

-bash: sudo: command not found

Himmelheiland, war sogar sudo deinstalliert worden?!

Immerhin su funktionierte, aber ich wollte dem Helfer nicht zumuten, das 32-stellige, zufällig generierte Passwort mühsam von iMessage auf die Laptop-Tastatur abzutippen.

Ich wollte schon aufgeben, da kam mir eine Blitzidee: Ich benötigte eine Reverse Shell unter dem nicht-privilegierten Benutzer, und dann könnte ich selber das Problem autonom lösen.

Das VPN war wegen eines Neustarts zusammengebrochen (genau dieser Server ist der entfernte Endpunkt), aber glücklicherweise hatte ich ein zweites System im entfernten Netzwerk, auf welchem ein SSH-Server mit einer öffentlichen IP lauscht. Ich war also zusätzlich parallel auf diesem zweiten Server eingeloggt. Zu diesem benachbarten Server sollte das Reverse Shell aufgebaut werden.

Eine Google-Suche lieferte folgende wichtigen Seiten zu Tage: Bind Shells and Reverse Shells with netcat, Hacking with Netcat part 2: Bind and reverse shells, Complete guide to Reverse Shells sowie Su: must be run from a terminal.

Der Bekannte gab nun auf dem zerschossenen Linux folgenden Befehl ein:

$ nc -lvp 12345 -e /bin/bash

Auf dem Schwester-Server gab ich dann ein:

$ nc -nv 10.1.2.3 12345

Wobei 10.1.2.3 die IP des zerschossenen Systems war.

Die Verbindung war zustande gekommen, aber ich sah keine richtige Shell. Befehle konnte ich eingeben (bspw. ls -l), und das Resultat wurde auf meinem Bildschirm angezeigt.

Problem: Als ich su ausführen wollte, wurde das mit der Fehlermeldung su : must be run from a terminal verhindert.

Zuerst überlegte ich mir den Weg über Scripts: How to pass the password to su/sudo/ssh without overriding the TTY? und su pass password to script.

Doch nach Konsultation von Getting around „su : must be run from a terminal“ schaffte ich eine wirklich vollständig brauchbare Shell nach Eingabe des folgenden Befehls:

python -c 'import pty; pty.spawn("/bin/bash")'

Einschub: Unter Stretch funktioniert das, unter Bullseye sollte man nun folgenden Befehle verwenden:

python3 -c 'import pty; pty.spawn("/bin/bash")'

Hurra, ich hatte eine Shell! Aber Achtung: Ein fahrlässiges, aus Gewohnheit gedrücktes Ctrl-C killt die netcat-Verbindung, nicht das laufende Programm.

Andere Varianten unter Zuhilfenahme anderer potentieller Bordmittel wie Perl, PHP etc. sind in Spawning a TTY Shell dokumentiert.

Nun also wollte ich su anwenden, realisierte erst dann aber, dass das in meiner Passwort-Datenbank hinterlegte 32 Zeichen lange Passwort nicht korrekt war. Ich hatte bei der Installation vergessen, dass viel zu einfache dummy-Passwort anzupassen … Als ich dieses eingegeben hatte, landete ich in einer root-Shell.

Doch oha: openssh-server liess sich wegen Abhängigkeitsproblemen nicht installieren.

Was nun? Ich musste irgendwie einen persistenten Server als ersten Brückenkopf einrichten, der beim versehentlichen Betätigen von Ctrl-C auf meiner Seite weiter lief und erneute Verbindungsversuche zuliess.

Ich überlegte mir, ein PHP-Backdoor-Script zu installieren (php-reverse-shell, Quellcode), doch wie konnte ich dieses so einrichten, dass es permanent oder periodisch automatisch Verbindungsversuche unternehmen würde?

Nach etwas tüfteln dann die viel einfachere Lösung:

# apt-get install telnetd

Besser wäre eigentlich gewesen:

# apt-get install telnetd-ssl

Via: How do I turn on telnet service on for a Linux / FreeBSD system?

Und nun hatte ich wieder einen „sauberen“ Zugang zum Server.

Die nachfolgenden Stunden verbrachte ich damit, den Server von Stretch auf Buster und dann auf Bullseye zu lüpfen und eine Ladung Pakete zu installieren, welche apt heimtückisch entfernt hatte: OpenSSH, sudo, cron, OpenVPN, Samba, monit.

Tags: , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 9. Mai 2021

setlocale: LC_ALL: cannot change locale

Seit ich mein MacBook Air mit M1-Chip und macOS Big Sur verwende, erhalte ich beim Login auf meinen Raspberry Pi 3 über SSH folgende Warnung zu Gesicht:

ssh dashboard
Linux DASHBOARD 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l
Last login: Sat May  8 05:00:24 2021
-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

Ursache des Problems: en_US.UTF-8 ist in /etc/locale.gen kommentiert:

$ cat /etc/locale.gen | grep -v "^#"

en_GB.UTF-8 UTF-8

Somit die Datei öffnen, die Zeile mit en_US.UTF-8 suchen, ent-kommentieren, speichern und dann folgenden Befehl ausführen:

# locale-gen

Via: warning: setlocale: LC_ALL: cannot change locale

Beim nächsten Login erscheint die Fehlermeldung nicht mehr.

Tags: , , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 3. April 2021

Ubiquiti UniFi UAP-AC-M zurücksetzen

Da heute um ungefähr 4 Uhr morgens mein Ubiquiti UniFi AP AC PRO plötzlich und ohne Vorwarnung verstorben ist (vermutlich, weil ich dessen Sendeleistung letzte Woche manuell auf High gesetzt habe …), musste ich ihn mit einem hier ungenutzt herumliegenden Ubiquiti UniFi UAP-AC-M ersetzen.

Leider klappte der Reset des noch für den vorherige Standort konfigurierten Access Points mit fünf Sekunden langem Druck auf den physischen Reset-Knopf nicht (wie im Handbuch auf Seite 7 beschrieben).

Schlussendlich loggte ich mich deshalb mittels SSH auf den Access Point ein (natürlich muss man dazu die Zugangsdaten der vorher genutzten Installation kennen, sonst hat man Pech), und führte folgenden Befehl aus:

# syswrapper.sh restore-default
Clearing CFG ... [%100] done!

Nach dem Neustart erschien der Access Point im Device Tab meines UniFi Controllers und konnte dort problemlos adoptiert werden.

Tags: , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 28. März 2021

Mit gehärtetem SSH-Client kann man sich nicht mehr auf UniFi-Geräte einloggen

$ ssh us-8-60w
Unable to negotiate with 10.1.2.3 port 22: no matching MAC found. Their offer: hmac-sha1

Bummer. Ich musste meine gehärtete ~/.ssh/config folgendermassen abschwächen, um mich per SSH wieder auf den Access Point einloggen zu können:

...
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-sha1
...

Siehe auch SSH Into Ubiquiti Access Point

Die lokal verfügbaren MACs zeigt man folgendermassen an:

$ $ ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 21. Februar 2018

SSH mit Benutzernamen und Passwort forcieren

Es gibt Momente, da möchte man nicht, dass der lokale ssh-agent alle vorhandenen Private Keys durchprobiert, um auf einen SSH-Server einzuloggen, sondern einem das Eingabefenster für das Passwort präsentiert.

Dies gelingt folgendermassen:

$ ssh -o PreferredAuthentications=keyboard-interactive,password -o PubkeyAuthentication=no 10.11.12.13

Via: SSH use only my password, Ignore my ssh key, don’t prompt me for a passphrase

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Samstag, 25. November 2017

Normalen Benutzern den SSH-Login auf Synology DiskStations erlauben

Mit dem Synology DiskStation Manager DSM 6.0 kam es zu Sicherheitsanpassungen beim SSH-Login: Selbst wenn ein Administrator auf einem Synology NAS SSH aktiviert, können sich normale Benutzer per SSH nicht auf dem NAS einloggen. Dies ist nur mit Benutzern möglich, die der Administrator-Gruppe zugeteilt sind.

Um diese Anpassung im Namen der Sicherheit rückgängig zu machen, bin ich dem Blog-Artikel Howto: (re-)Enable SCP/SSH Login on Synology DSM 6.0 for non admin users [UPDATE] gefolgt. Der Grund ist trivial: Synology setzt für normale Benutzer in /etc/passwd ein unbrauchbares Login-Shell: /sbin/nologin

Die Lösung: Ein auf dem NAS hinterlegtes bash-Script wird mittels Cron-Job unter root laufend alle fünf Minuten ausgeführt und ersetzt die Login-Shell ausgewählter Benutzer mit /bin/sh.

/volume1/homes/admin/enable-ssh-logins.sh

#!/bin/bash
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^dagobert\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^donald\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^daisy\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^huey\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^dewey\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^louie\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd

exit 0

Cron-Job über DiskStation Manager Web-Oberfläche einrichten

  • Control Panel
  • Task Scheduler
  • Create
  • User-defined script
  • General
    • Task: „Enable Login Shell“
    • User: root
  • Schedule
    • [x] Run on the following days: Daily
    • Frequency: Every 5 minute(s)
  • Task Settings
    • Run command: User-defined script: /volume1/homes/admin/enable-ssh-logins.sh

Tags: , , , ,
Labels: Uncategorized

3 Kommentare | neuen Kommentar verfassen

Sonntag, 5. November 2017

SSH meldet „Bad SSH2 Mac spec“

Meine ~/.ssh/config habe ich gemäss den Empfehlungen von Mozilla konfiguriert.

Offenbar gab es Anpassungen am SSH-Client unter macOS, als ich zu Monatsbeginn (1. November) MacPorts aktualisiert habe.

Es waren keine Logins auf irgendwelche in config konfigurierten Server mehr möglich. Die Fehlermeldung lautete:

$ ssh sauron
/Users/mario/.ssh/config line 8: Bad SSH2 Mac spec 'hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96'.

Hmmm! Mit folgendem Befehl findet man raus, welche SSH2 Macs der SSH-Client mittlerweile nur noch unterstützt:

$ ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

Ich speicherte beide Werte in unterschiedlichen Textdateien, wobei ich die Werte aus der config von Hand auf einen Wert pro Zeile aufspaltete. Danach sortierte ich diese mit sort, um sie besser vergleichbar zu machen.

Ein Diff der beiden Listen zeigte mir schlussendlich klar auf, wo ich Hand anlegen musste:

$ diff ssh-enabled-sorted.txt ssh-available-sorted.txt 
3,4c3,4
< hmac-ripemd160
< hmac-ripemd160@openssh.com
---
> hmac-md5-96-etm@openssh.com
> hmac-md5-etm@openssh.com
6a7,8
> hmac-sha1-96-etm@openssh.com
> hmac-sha1-etm@openssh.com
12a15,16
> umac-64-etm@openssh.com
> umac-64@openssh.com

Damit konnte ich config anpassen. Vorher:

...
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
...

Nachher (hmac-ripemd160,hmac-ripemd160@openssh.com entfernt):

...
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com,hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
...

Tags: , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 31. August 2016

Server mit vergessenen SSH-Schlüsseln ausfindig machen

Vor einigen Tagen habe ich das Schlüsselmanagement für meine SSH-Zugänge völlig umgekrempelt.

Da ich auf Nummer sicher gehen wollte, dass ich den alten Private Key nicht auf bei mir in Vergessenheit geratenen Systemen übersehen hatte, analysierte ich in den Folgetagen die Log-Datei /var/log/auth.log auf meinem zentralen Linux-Server.

Sucht man mittels cat | grep nach „Failed“, erhält man Einträge in der folgenden Form:

...
Aug 25 22:37:09 ALPHA sshd[8539]: Failed publickey for %user% from 85.X.X.X
...

Dies ist aber nur der Beginn der Nachforschung — als nächstes muss man stark hirnen, auf welchem Server das betreffende Script laufen könnte — schliesslich gibt ssh nur eine öffentliche IP-Adresse aus (der verursachende Server steht hinter einem NAT-Router und besitzt eine private IP).

Tags: , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Montag, 23. Mai 2016

Passwort eines Asus RT-AC66U per SSH zurücksetzen

Die Idee war rückblickend doch nicht so genial, das Benutzerpasswort meines Asus RT-AC66U mit Merlin-Firmware ein Sonderzeichen enthalten zu lassen.

Glücklicherweise hatte ich meinen öffentlichen SSH-Schlüssel auf dem Router hinterlegt und konnte mich so zumindest per SSH einloggen. Einmal auf der Kommandozeile, führte ich folgende Befehle aus:

# nvram show | grep http_passwd
http_passwd=?einganzlangespasswort
# nvram set http_passwd="12345678"
# nvram commit

Quelle: DD-WRT :: NVRAM

Anschliessend funktionierte der Login über die Web-Oberfläche wieder.

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. April 2016

Den eigenen SSH Public Key auf einem UniFi Access Point hinterlegen

Um sich ohne Passwort auf einen UniFi Access Point einzuloggen, ist der SSH Public Key auf dem Access Point in folgender Datei zu hinterlegen:

Persistent

Folgende Anpassungen überlebt Reboots des Access Points und ist dementsprechend die einzig zuverlässige Variante ohne böse Überraschungen.

Auf dem Server, der als UniFi-Controller dient, legt man eine Datei namens config.properties an, die folgende Zeilen enthält:

config.system_cfg.1=sshd.auth.key.1.status=enabled
config.system_cfg.2=sshd.auth.key.1.value=AAA...== Beschreibung des Public Keys 1
config.system_cfg.3=sshd.auth.key.1.type=ssh-rsa

config.system_cfg.4=sshd.auth.key.2.status=enabled
config.system_cfg.5=sshd.auth.key.2.value=AAA...== Beschreibung des Public Keys 2
config.system_cfg.6=sshd.auth.key.2.type=ssh-rsa

config.system_cfg.7=sshd.auth.key.3.status=enabled
config.system_cfg.8=sshd.auth.key.3.value=AAA...== Beschreibung des Public Keys 3
config.system_cfg.9=sshd.auth.key.3.type=ssh-rsa

config.system_cfg.10=sshd.auth.key.4.status=enabled
config.system_cfg.11=sshd.auth.key.4.value=AAA...== Beschreibung des Public Keys 4
config.system_cfg.12=sshd.auth.key.4.type=ssh-rsa

Im obigen Beispiel konfiguriere ich insgesamt vier Public Keys (sshd.auth.key.1 bis sshd.auth.key.4). Wer nur einen Schlüssel hinterlegen muss, pflegt dementsprechend nur die ersten drei Zeilen in die Datei ein.

Dem Wert sshd.auth.key.1.value weist man den ganzen Public Key zu, ohne aber den Typ (bei mir ssh-rsa) zu erwähnen. Auch Anführungszeichen sind nicht nötig, wenn dem Public Key noch eine Beschreibung mit Leerschlägen folgt (ist bei mir der Fall).

Der Pfad zu dieser Datei hängt vom Betriebssystem und den im Controller definierten Site-Namen ab. Bei mir (Debian GNU/Linux, Site-Name „default“) lautet der Pfad /var/lib/unifi/sites/default/config.properties.

Die Inspiration für dieses Prozedere habe ich dem Artikel UniFi – Add Custom SSH Keys to Your UniFi Devices entnommen.

Den Site-Namen findet man mit folgender Anleitung heraus: UniFi – config.properties File Explanation. Weitere Optionen (bspw. Public Keys, die nur auf einzelne Access Points ausgerollt werden) findet man im Artikel UniFi – How to make persistent changes to UAP(s) system.cfg.

Nicht persistent

Folgende, je nach Firmware unterschiedliche Methoden, erlauben ebenfalls den passwortlosen Login. Nach dem nächsten Neustart des Access Points müssen die Schritte aber zwingend wiederholt werden — die Anpassungen sind nicht persistent.

Firmware 3.4.19

/etc/persistent/.ssh/authorized_keys

Via: ssh key based auth

Wie ich im Januar 2017 bemerken musste, konnte ich mich so nicht mehr mit meinen SSH-Schlüsseln auf die UniFi Access Points einloggen. Nach einer Stunde debuggen dann endlich die Erkenntnis:

Firmware 3.7.28.5442

/etc/dropbear/authorized_keys

Evtl. ist auch noch folgender Befehl nötig (das merke ich spätestens beim nächsten Reboot):

# cfgmtd -w -p /etc

Quelle: Unifi AP: Maintaining SSH access whilst disabling password logins (authorized_keys only) sowie Hacking the KanKun Smartplug – HowTo: Login to SSH on BusyBox (DropBear) Without a Password

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen