Zu vermutendes Problem (Bitte an die Admins weiterleiten!)
bearbeitet von Raketenwilli> Meine Header der Mail:
>
> ~~~
> From: till.stukenbrok@uni-bielefeld.de
> Subject: Ihr Konto wurde gehackt
> Date: Fri, 13 Dec 2030 07:15:52 +0000
> To: till.stukenbrok@uni-bielefeld.de
> Received: from domain.com (unknown [1.1.1.1])
> by imf08.b.hostedemail.com (Postfix) with ESMTP
> for <till.stukenbrok@uni-bielefeld.de>; Mon, 13 Dec 2030 07:15:52 +0000 (UTC)
> Content-Type: multipart/related;
> boundary="2837fewuhs983uwehfsnuewsdaj23iwqodsa"
> X-Message-Flag: Flag for follow up
> X-Priority: 1 (Highest)
> X-MSMail-Priority: High
> Importance: High
> MIME-Version: 1.0
> ~~~
>
> **ich wusste nicht das der 13te zwei Wochentage hat** 😀
**UPS!**
Dann hat wohl auch die UNI Bielefeld das Problem, dass mit dem Benutzerkennzeichen und dem Passwort ein Benutzerzugang via SSH möglich ist. (Shell auf `/bin/false` oder `/usr/sbin/nologin` statt `/bin/sh` oder `/bin/bash` stellen und in der sshd-Konfiguaration den Zugang zusätzlich verbieten.
Die Admins mögen auch gleich untersuchen, ob der vermeintliche Mail-Benutzer (aus dem Userpart der Mailaddresse) ein anderes Home als `/nonexistent` hat und ob darin womöglich ein Ordner `.ssh` mit einer Datei `authorized_keys` existiert. **Dann könnte sich der Angreifer nämlich auch nach der Passwortänderung mit seinem selbst angelegtem SSH-Key einloggen.**
Das übereinstimmende
~~~
boundary="2837fewuhs983uwehfsnuewsdaj23iwqodsa"
~~~
sag mir das es derselbe oder die selbe Gruppe von Angreifern ist.
**Wahrscheinlich muss so Einiges von der Infrastruktur platt gemacht und neu aufgesetzt werden.**
Zu vermutendes Problem (Bitte an die Admins weiterleiten!)
bearbeitet von Raketenwilli> Meine Header der Mail:
>
> ~~~
> From: till.stukenbrok@uni-bielefeld.de
> Subject: Ihr Konto wurde gehackt
> Date: Fri, 13 Dec 2030 07:15:52 +0000
> To: till.stukenbrok@uni-bielefeld.de
> Received: from domain.com (unknown [1.1.1.1])
> by imf08.b.hostedemail.com (Postfix) with ESMTP
> for <till.stukenbrok@uni-bielefeld.de>; Mon, 13 Dec 2030 07:15:52 +0000 (UTC)
> Content-Type: multipart/related;
> boundary="2837fewuhs983uwehfsnuewsdaj23iwqodsa"
> X-Message-Flag: Flag for follow up
> X-Priority: 1 (Highest)
> X-MSMail-Priority: High
> Importance: High
> MIME-Version: 1.0
> ~~~
>
> **ich wusste nicht das der 13te zwei Wochentage hat** 😀
**UPS!**
Dann hat wohl auch die UNI Bielefeld das Problem, dass mit dem Benutzerkennzeichen und dem Passwort ein Benutzerzugang via SSH möglich ist. (Shell auf `/bin/false` oder `/usr/sbin/nologin` statt `/bin/sh` oder `/bin/bash` stellen und in der sshd-Konfiguaration den Zugang zusätzlich verbieten.
Die Admins mögen auch gleich untersuchen, ob der vermeintliche Mail-Benutzer (aus dem Userpart der Mailaddresse) ein anderes Home als `/nonexistent` hat und ob darin womöglich ein Ordner `.ssh` mit einer Datei `authorized_keys` existiert. **Dann könnte sich der Angreifer nämlich auch nach der Passwortänderung mit seinem selbst angelegtem SSH-Key einloggen.**
**Wahrscheinlich muss so Einiges von der Infrastruktur platt gemacht und neu aufgesetzt werden.**
Zu vermutendes Problem (Bitte an die Admins weiterleiten!)
bearbeitet von Raketenwilli> Meine Header der Mail:
>
> ~~~
> From: till.stukenbrok@uni-bielefeld.de
> Subject: Ihr Konto wurde gehackt
> Date: Fri, 13 Dec 2030 07:15:52 +0000
> To: till.stukenbrok@uni-bielefeld.de
> Received: from domain.com (unknown [1.1.1.1])
> by imf08.b.hostedemail.com (Postfix) with ESMTP
> for <till.stukenbrok@uni-bielefeld.de>; Mon, 13 Dec 2030 07:15:52 +0000 (UTC)
> Content-Type: multipart/related;
> boundary="2837fewuhs983uwehfsnuewsdaj23iwqodsa"
> X-Message-Flag: Flag for follow up
> X-Priority: 1 (Highest)
> X-MSMail-Priority: High
> Importance: High
> MIME-Version: 1.0
> ~~~
>
> **ich wusste nicht das der 13te zwei Wochentage hat** 😀
**UPS!**
Dann hat wohl auch die UNI Bielefeld das Problem, dass mit dem Benutzerkennzeichen und dem Passwort ein Benutzerzugang via SSH möglich ist. (Shell auf `/bin/false` oder `/usr/sbin/nologin` statt `/bin/sh` oder `/bin/bash` stellen und in der sshd-Konfiguaration den Zugang zusätzlich verbieten.
Die Admins mögen auch gleich untersuchen, ob der Benutzer (aus dem Userpart der Mailaddresse) ein anderes Home als /nonexistent hat und ob darin womöglich ein Ordner `.ssh` mit einer Datei `authorized_keys` existiert. **Dann könnte sich der Angreifer nämlich auch nach der Passwortänderung mit seinem selbst angelegtem SSH-Key einloggen.**
**Wahrscheinlich muss so Einiges von der Infrastruktur platt gemacht und neu aufgesetzt werden.**
Zu vermutendes Problem (Bitte an die Admins weiterleiten!)
bearbeitet von Raketenwilli> Meine Header der Mail:
>
> ~~~
> From: till.stukenbrok@uni-bielefeld.de
> Subject: Ihr Konto wurde gehackt
> Date: Fri, 13 Dec 2030 07:15:52 +0000
> To: till.stukenbrok@uni-bielefeld.de
> Received: from domain.com (unknown [1.1.1.1])
> by imf08.b.hostedemail.com (Postfix) with ESMTP
> for <till.stukenbrok@uni-bielefeld.de>; Mon, 13 Dec 2030 07:15:52 +0000 (UTC)
> Content-Type: multipart/related;
> boundary="2837fewuhs983uwehfsnuewsdaj23iwqodsa"
> X-Message-Flag: Flag for follow up
> X-Priority: 1 (Highest)
> X-MSMail-Priority: High
> Importance: High
> MIME-Version: 1.0
> ~~~
>
> **ich wusste nicht das der 13te zwei Wochentage hat** 😀
**UPS!**
Dann hat wohl auch die UNI Bielefeld das Problem, dass mit dem Benutzerkennzeichen und dem Passwort ein Benutzerzugang via SSH möglich ist. (Shell auf `/bin/false` oder `/usr/sbin/nologin` statt `/bin/sh` oder `/bin/bash` stellen und in der sshd-Konfiguaration den Zugang zusätzlich verbieten.
Die Admins mögen auch gleich untersuchen, ob der Benutzer ein Home hat und ob darin womöglich ein Ordner `.ssh` mit einer Datei `authorized_keys` existiert.
**Wahrscheinlich muss so Einiges von der Infrastruktur platt gemacht und neu aufgesetzt werden.**