Posts Tagged ‘OOB’

Montag, 3. April 2023

OAuth gegen Google Kalender hat sich geändert

Ich habe mir auf einem Linux-Server verschiedene Cron-Jobs eingerichtet, welche Python-Scripts gegen Google Kalender ausführen.

Das eine Script sendet mir und meiner Frau Hinweise per Email, wenn sich in der letzten Stunde bis 30 Tage in der Zukunft liegende Kalendereinträge geändert haben. Ein anderes Script schaltet Kalendereinträge, die ich aus dem SBB-Fahrplan eingetragen habe, auf die Standardsichtbarkeit (anstelle „Privat“).

Letzte Woche funktionierten beide Scripts nicht mehr. Ursache: Google hat die OAuth-Authentifizierung angepasst, und sicherer gemacht (Migrationsanleitung). Das von mir aus dem Internet zusammenkopierte, in Trial & Error zum Funktionieren gebrachte Login-Verfahren funktioniert nicht mehr:

Nach ein wenig Herumpröbeln schaut so die Lösung aus:

...
from googleapiclient.discovery import build
from httplib2 import Http
from oauth2client import file, client, tools

# Added 2023-03
from google.auth.transport.requests import Request
from google.oauth2.credentials import Credentials
from google_auth_oauthlib.flow import InstalledAppFlow
...
googleCredentialsFile = scriptdir + '/token-readonly.json'
SCOPES = ['https://www.googleapis.com/auth/calendar.readonly']
...
creds = None
if os.path.exists(googleCredentialsFile):
    creds = Credentials.from_authorized_user_file(googleCredentialsFile, SCOPES)
if not creds or not creds.valid:
    if creds and creds.expired and creds.refresh_token:
        creds.refresh(Request())
    else:
        flow = InstalledAppFlow.from_client_secrets_file("credentials.json", SCOPES)
        creds = flow.run_local_server(port=0)
    with open(googleCredentialsFile, "w") as token:
        token.write(creds.to_json())

service = build('calendar', 'v3', credentials=creds)
...

Nebenbemerkung: Beim Debuggen der (nun nicht mehr funktionierenden) Original-Routine stolperte ich auch noch über folgendes Problem: Why is oauth2client run_flow giving an Argparse error?

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

Keine Kommentare | neuen Kommentar verfassen

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, 8. Juli 2018

Endlich ist es da: Die M2M- resp. OOB-SIM für Normalsterbliche

Seit Jahr und Tag bin ich auf der Suche nach einer Daten-SIM-Karte, welche ich als Out-of-Band-Lösung in meinen drei Netzwerk-Standorten installieren kann.

Die SIM möchte ich in ein UMTS-Modem einbauen, welches ich entweder extern per USB oder intern per Einbau an den ThinkPad-„Server“ der jeweiligen Location anhänge.

Fällt das Internet aus, oder verliere ich aus irgendeinem Grund den Remote-Zugriff ins LAN, aktiviert sich die SIM-Karte von alleine, meldet seine IP bei einem Dienst wie DynDNS, öffnet einen VPN-Tunnel und bietet mir so die Möglichkeit, Probleme aus der Ferne zu diagnostizieren.

Mit SimplyMobile von Swisscom scheint das nun Realität zu werden:

  • Prepaid-SIM, d.h. keine monatlich wiederkehrenden Kosten
  • Datenpaket von 750 MB für 9.90 CHF
  • Datenguthaben verfällt nicht

Quelle: SIMPLYMOBILE PREPAID

Fazit: Das Basteln kann beginnen!

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

Keine Kommentare | neuen Kommentar verfassen