Habe eine Sicherheitslücke im "Server" (Linux) und bräuchte dringend Hilfe.

Triebwerk · Apr 2, 2018

Hallo Zusammen,

das ist mein erster Post hier im Forum und hoffe ich habe die richtige Kategorie erwischt. Ab jetzt mach ich's so kurz ich kann.
Ich habe einen Raspberry Pi 3 im Netzwerk als Server laufen der per DDNS aus dem Internet erreichbar ist. Vor ca. 30 Min. habe ich Dateien in meinem "/shared" Laufwerk entdeckt, die ich nie dort gespeichert habe (*.so - Dateien). Hab mir die Dateien mal mit einem Texteditor angesehen und bin mir ziemlich sicher gehacked worden zu sein. Es wurde eine Datei aus dem Internet heruntergeladen umbenannt und die Originaldatei wieder gelöscht. Soweit konnt ich das mit der Texteditor Methode nachvollziehen. Die Datei selbst ist momentan noch im unter dem Pfad der im Texteditor erscheint zu finden und trägt den vielsagenden Namen (db.dat). Kennt jemand vielleicht die Datei oder kann mir vielleicht irgendwie weiterhelfen ??

Habe auf dem Server Apache, MySQL, MiniDLNA, Samba, Pi-Hole und Artillery laufen und syslog, user.log und auth.log zeigen keine verdächtigen Einträge.

Ich bin für jede Hilfe an diesem Ostermontag spätabend dankbar.

Vorab vielen Dank.

TW

killerbees19 · Apr 3, 2018

Wurden immer alle Updates installiert?
Welche Ports sind über das Internet erreichbar?

Wenn ich raten müsste, würde ich spontan auf CVE-2017-7494 tippen.

mr_brain · Apr 3, 2018

"/shared" Laufwerk (Samba) und "aus dem Internet erreichbar" . Äh, warum wundert es mich nicht, dass dort irgendwelche Dateien von Fremden abgelegt werden.

Triebwerk · Apr 3, 2018

Erts mal vielen Dank für die Hilfen.

Guten Morgen,

Updates wurden immer gemacht (täglich).

Unter den offenen Ports bin ich fündig geworden. Es laufen Prozesse wie /run/user/0/gnupg/S.gpg-agent.ssh oder /run/user/999/gnupg/S.gpg-agent.browser das sind scheinbar die Files die mit db.dat heruntergeladen wurden. Sie sind aber anders benannt worden lt. Text Editor.

Hab die Dateien entfernt, die werden aber nach einem reboot wiederhergestellt, jetzt muss ich nur rausfinden wo die Wiederherstellung geregelt wird. Hat jemand eine Idee ??

P.S.: Der Samba Server ist auf Benutzerebene schon abgesichert, aber scheinbar nicht gut genug. Darum kümmere ich mich wenn ich den Rest im griff hab'.

Deleted member 15972 · Apr 3, 2018

Triebwerk said:
[...]
Hab die Dateien entfernt, die werden aber nach einem reboot wiederhergestellt, jetzt muss ich nur rausfinden wo die Wiederherstellung geregelt wird. Hat jemand eine Idee ?? [...]

Scheinbar wurde da noch zusätzliche Software installiert, wenn sich Dateien wiederherstellen. Ich persönlich würde die SD Karte auf einem sauberen System mounten und mir dann mal das Filesystem genau ansehen: nachsehen, welche Servicefiles vorhanden sind und ob ggfls. auch noch Kernelmodule vorhanden sind, die nicht vorhanden sein sollten.

marce · Apr 3, 2018

Also wegen der /run/user/0/gnupg/S.gpg-agent.ssh musst Du Dir keine Sorgen machen...

Deleted member 15972 · Apr 3, 2018

Ach sorry, nicht darauf geachtet, dass das in /run ist. Ich bezog das immer noch auf /share wobei er es natürlich deutlich geschrieben hat aber ich es überlesen habe. Asche auf mein Haupt.

marce · Apr 3, 2018

Vielleicht sollte der TE ein wenig deutlicher werden, was er denn nun gefunden hat und was seiner Meinung nach an Prozessen sonst noch läuft und welche Datei er wie wo analysiert hat...

Triebwerk · Apr 3, 2018

So folgende Prozesse laufen:

Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 102914 18706/systemd /run/user/0/gnupg/S.gpg-agent.extra
unix 2 [ ACC ] STREAM LISTENING 102917 18706/systemd /run/user/0/gnupg/S.gpg-agent.browser
unix 2 [ ACC ] STREAM LISTENING 102919 18706/systemd /run/user/0/gnupg/S.gpg-agent
unix 2 [ ACC ] STREAM LISTENING 102921 18706/systemd /run/user/0/gnupg/S.gpg-agent.ssh
unix 2 [ ACC ] STREAM LISTENING 15429 623/systemd /run/user/999/gnupg/S.gpg-agent
unix 2 [ ACC ] STREAM LISTENING 15432 623/systemd /run/user/999/gnupg/S.gpg-agent.ssh
unix 2 [ ACC ] STREAM LISTENING 15434 623/systemd /run/user/999/gnupg/S.gpg-agent.browser
unix 2 [ ACC ] STREAM LISTENING 15436 623/systemd /run/user/999/gnupg/S.gpg-agent.extra
unix 2 [ ACC ] STREAM LISTENING 9062 1/init /var/run/dbus/system_bus_socket
unix 2 [ ACC ] STREAM LISTENING 9065 1/init /var/run/avahi-daemon/socket
unix 2 [ ACC ] STREAM LISTENING 9068 1/init /run/thd.socket
unix 2 [ ACC ] STREAM LISTENING 13190 1904/python3 /var/run/fail2ban/fail2ban.sock
unix 2 [ ACC ] STREAM LISTENING 14758 817/php-cgi /var/run/lighttpd/php.socket-0
unix 2 [ ACC ] STREAM LISTENING 936 1/init /run/systemd/private
unix 2 [ ACC ] STREAM LISTENING 944 1/init /run/systemd/fsck.progress
unix 2 [ ACC ] STREAM LISTENING 15282 1778/nmbd /var/run/samba/nmbd/unexpected
unix 2 [ ACC ] STREAM LISTENING 958 1/init /run/systemd/journal/stdout
unix 2 [ ACC ] STREAM LISTENING 12223 623/systemd /run/user/999/systemd/private
unix 2 [ ACC ] STREAM LISTENING 17608 965/mysqld /var/run/mysqld/mysqld.sock
unix 2 [ ACC ] SEQPACKET LISTENING 967 1/init /run/udev/control
unix 2 [ ACC ] STREAM LISTENING 102909 18706/systemd /run/user/0/systemd/private

Die Liste der Ports halte ich für zu lange um sie hier zu posten, sind aber einige durch Artillery.

Die Dateien die ich versucht habe auszulesen heissen z.B. "6zM7Xg8cPk.so" also scheinen zufällig benannt. In diesen ist u.A. die URL der heruntergeladenen Datei (db.dat).

Thunderbyte · Apr 3, 2018

Lass mich raten: Du hast den Raspi mit grafischem X Desktop installiert und irgendwann mal angegeben, dass Deine Passwörter gespeichert werden sollen?

gpg-agent is a daemon to manage secret (private) keys independently from any protocol. It is used as a backend for gpg and gpgsm as well as for a couple of other utilities.

Mir kommt an den geposteten Ports aktuell nichts verdächtig vor. Da werden wir wohl eine komplette Liste aller Prozesse brauchen. Woher willst Du wissen, welcher Ausschnitt relevant ist, wenn Du die "Sicherheitslücke" nicht selbst finden kannst?

Ist schon eine gewisse Ironie, wenn man sich https://github.com/BinaryDefense/artillery (u.a. Honeypot, der Ports aufmacht) aufsetzt und dann das Gefühl hat, gehackt worden zu sein.

Triebwerk · Apr 3, 2018

Nein, tut mir leid, weder habe ich Raspian mit grafischer Oberfläche installiert, noch irgendwelche Passwörter gespeichert.

Okay, hier die komplette Liste, aber nicht dass jetzt jemand kommt und sagt ich habe gegen Forenregeln verstossen.

Code:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      748/pihole-FTL
tcp        0      0 0.0.0.0:5800            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:8200            0.0.0.0:*               LISTEN      1718/minidlnad
tcp        0      0 0.0.0.0:3401            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:9290            0.0.0.0:*               LISTEN      337/python
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      965/mysqld
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      2078/smbd
tcp        0      0 127.0.0.1:6379          0.0.0.0:*               LISTEN      762/redis-server 12
tcp        0      0 0.0.0.0:xxxx           0.0.0.0:*               LISTEN      662/sshd
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:110             0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:10000           0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      784/lighttpd
tcp        0      0 0.0.0.0:2323            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:8180            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      675/dnsmasq
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:8888            0.0.0.0:*               LISTEN      549/perl
tcp        0      0 0.0.0.0:8889            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:1337            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:1433            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:25              0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:1723            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:44443           0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:9020            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:3421            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      2078/smbd
tcp        0      0 0.0.0.0:1024            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:8545            0.0.0.0:*               LISTEN      337/python
tcp        0      0 0.0.0.0:16993           0.0.0.0:*               LISTEN      337/python
tcp6       0      0 :::XXXX                :::*                    LISTEN      662/sshd
tcp6       0      0 :::139                  :::*                    LISTEN      2078/smbd
tcp6       0      0 :::80                   :::*                    LISTEN      784/lighttpd
tcp6       0      0 :::53                   :::*                    LISTEN      675/dnsmasq
tcp6       0      0 :::445                  :::*                    LISTEN      2078/smbd
udp        0      0 0.0.0.0:5353            0.0.0.0:*                           320/avahi-daemon: r
udp        0      0 239.255.255.250:1900    0.0.0.0:*                           1718/minidlnad
udp        0      0 0.0.0.0:42497           0.0.0.0:*                           320/avahi-daemon: r
udp        0      0 0.0.0.0:53              0.0.0.0:*                           675/dnsmasq
udp        0      0 192.168.1.5:48742       0.0.0.0:*                           1718/minidlnad
udp        0      0 192.168.1.5:123         0.0.0.0:*                           683/ntpd
udp        0      0 127.0.0.1:123           0.0.0.0:*                           683/ntpd
udp        0      0 0.0.0.0:123             0.0.0.0:*                           683/ntpd
udp        0      0 192.168.1.255:137       0.0.0.0:*                           1778/nmbd
udp        0      0 192.168.1.5:137         0.0.0.0:*                           1778/nmbd
udp        0      0 0.0.0.0:137             0.0.0.0:*                           1778/nmbd
udp        0      0 192.168.1.255:138       0.0.0.0:*                           1778/nmbd
udp        0      0 192.168.1.5:138         0.0.0.0:*                           1778/nmbd
udp        0      0 0.0.0.0:138             0.0.0.0:*                           1778/nmbd
udp6       0      0 :::5353                 :::*                                320/avahi-daemon: r
udp6       0      0 :::40196                :::*                                320/avahi-daemon: r
udp6       0      0 :::53                   :::*                                675/dnsmasq
udp6       0      0 fe80::ba27:ebff:fea:123 :::*                                683/ntpd
udp6       0      0 ::1:123                 :::*                                683/ntpd
udp6       0      0 :::123                  :::*                                683/ntpd

Nur meinen SSH Port habe ich "zensiert".

Viele Grüsse
TW

rebuyit · Apr 4, 2018

Wie sehen den deine Portfreigaben im Router aus?
Welche Dienste läst du von Ausen auf dein Pi erreichen?

Also nicht nur die Services die lokal auf deinem Pi laufen sondern auch die Ports die du nach ausen aufgemacht hast wären mal intressant!

Welche Samba Version setzt du aktuell ein?

user.log und auth.log würden nur einen Hinweis darauf geben wenn sich jemand via PAM bsp mit SSH auf deine Kiste Verbindet.

nen Syslog Auszug wäre da schon hilfreicher

Ic

Triebwerk · Apr 4, 2018

Also die Syslog habe ich mir jetzt nochmal durch geschaut, aber auch dort nichts verdächtiges gefunden.

Was den Router angeht glaube ich liess ich alle Ports <60000 durch. Hab mich da voll auf Artillery verlassen und das funktionierte eingentlich auch immer. Hatte mich selbst aus versehen 3 mal "ausgesperrt".

Die Samba Version ist die 4.5.12 und die habe ich ja auch durch die täglichen updates aktuell gehalten.

So als kleinen Zwischenbericht: Keine "fremden" Dateien mehr seit 2 Tagen. Das bleibt hoffentlich auch so, aber dennoch hab ich noch nicht viel mehr rausgefunden. Und ja, ich hab' schiss, dass das wieder passiert.

Joe User · Apr 4, 2018

Warum lauscht Python bei Dir auf dutzenden Ports?
Warum sind (fast) alle Dienste auf 0.0.0.0/::0 gebunden?

Samba current stable ist 4.8.0, Dein Samba ist also nicht stable.
Samba legacy versions sind: 4.7.6, 4.6.14, 4.5.16
Auch in dem legacy Zweig Deiner Samba Version ist Dein Samba alles Andere als aktuell und enthält mindestens 10 Security Bugs von denen 8 ein CVE erhalten haben.

Der Rest des Systems dürfte ähnlich veraltet und unsicher sein...

Thunderbyte · Apr 4, 2018

Triebwerk said:
Was den Router angeht glaube ich liess ich alle Ports <60000 durch. Hab mich da voll auf Artillery verlassen und das funktionierte eingentlich auch immer. Hatte mich selbst aus versehen 3 mal "ausgesperrt".

Wieso zum Geier würde man so etwas dummes machen?

Wieso willst Du mit einer Software "böse Buben" fangen, indem Du sie erst mal reinlässt, wenn sie gar rein kämen, wenn einfach nur die Türe zu wäre?

Es werden im Router wirklich nur SELEKTIV die absolut notwendigen Ports weitergeleitet. Dann brauchst Du auch Artillery nicht.

marce · Apr 4, 2018

Joe User said:
Samba current stable ist 4.8.0, Dein Samba ist also nicht stable.
Samba legacy versions sind: 4.7.6, 4.6.14, 4.5.16

Die aktuelle vom Raspbian ausgelieferte Version ist die 4.5.12 - und in der dürften alle Bugs gefixed sein via Backports.

Du könntest endlich mal einsehen, daß nicht nur die aktuellste Version die einzig wahre ist sondern daß eben Distributionen auch "alte" Versionen (aber trotzdem komplett gepflegt und gepatcht) ausliefern...
Nennt sich Version-Pinning. Macht eigentlich niemand, nur Debian, Novell, RedHat und jede andere Distribution, die Release-Basiert arbeitet...

Triebwerk · Apr 4, 2018

Hey, ich will hier keinen Streit auslösen.

Was den Router angeht, so ist das gefixed. War klar mein Fehler ! Artillery lass ich aber dennoch weiterlaufen.

Ich bin mir sicher, dass die Updates täglich laufen/liefen !! Samba hat bisher nie Probleme gemacht (Sicherheitstechnisch).

Thunderbyte · Apr 4, 2018

Triebwerk said:
Was den Router angeht, so ist das gefixed. War klar mein Fehler ! Artillery lass ich aber dennoch weiterlaufen.

Artillery beruht anscheinend darauf, dass es typische Angriffsports exposed, um als "Honeypot" Angriffe zu sammeln und dann zu sperren. Nochmal: wenn diese Ports nicht offen sind, werden auch Angreifer keinen Angriffspunkt haben. Man öffnet nur die paar Ports, die man unbedingt braucht (weil die Initiierung der Verbindung von außen kommt) und lässt alles andere zu. Ich habe noch nie von Artillery gehört, weil es m.E. bei einem vernünftig konfigurierten System, bei dem man nicht einfach mal scheunentorgleich ALLE PORTS ÖFFNET nicht nötig ist. Viel wichtiger als das "Wegfangen" wäre das vernünftige Konfigurieren und Aktualisieren der Dienste, die einen Zugang von außen haben.

Und nochmal: wenn Du alle Ports aufmachst, brauchst Du Dich nicht wundern, wenn Hackversuche kommen und ggfalls auch erfolgreich sind. Die Sicherheitslücke Deines Servers war in erster Linie mal eine falsche Herangehensweise an das Thema Sicherheit und Deine eigene Schuld.

Ich bin mir sicher, dass die Updates täglich laufen/liefen !! Samba hat bisher nie Probleme gemacht (Sicherheitstechnisch).

Hast Du manuell das System täglich aktualisiert? Woher willst Du wissen, ob Samba bisher nie sicherheitstechnische Probleme gemacht hat, wenn Du nicht mal weißt, wie Du den Server sichern sollst? Soll kein Angriff sondern aufzeigen, wo evtl Deine Denkfehler sind.

Triebwerk · Apr 4, 2018

Thunderbyte said:
Hast Du manuell das System täglich aktualisiert?

Klingt jetzt vielleicht dumm, aber ja habe ich. Das ist mein einziger "Server" und die Zeit habe ich mir einfach genommen.

Das mit den Ports hab ich ja gesagt war mein Fehler und ist jetzt behoben. Vielleicht ist auch deshalb seit dem nichts mehr passiert *klopf-auf-holz*

Joe User · Apr 5, 2018

marce said:
Die aktuelle vom Raspbian ausgelieferte Version ist die 4.5.12 - und in der dürften alle Bugs gefixed sein via Backports.

Nope, die (Security)Bugs aus https://www.samba.org/samba/history/samba-4.5.13.html sind laut http://metadata.ftp-master.debian.org/changelogs/main/s/samba/samba_4.5.12+dfsg-2+deb9u2_changelog nicht gefixt. Ebenso sind alle nicht im Samba-Changelog explizit aufgeführten (Security)Bugs nicht gefixt.

marce said:
Du könntest endlich mal einsehen, daß nicht nur die aktuellste Version die einzig wahre ist sondern daß eben Distributionen auch "alte" Versionen (aber trotzdem komplett gepflegt und gepatcht) ausliefern...

Du und die anderen Debian-Fanboys könnten endlich mal einsehen, dass bei Debian (und Derivaten) im Regelfall nur CVEs backported werden und alle anderen (Security)Bugs ignoriert werden, unter Anderem um den "Security-Track" künstlich klein zu halten und auch um die Maintainer nicht zu überfordern... Gibt noch mehr Gründe für dieses Verhalten, die sind den Debian-Devs bekannt und peinlich und haben in der Öffentlichkeit nicht viel zu suchen, das muss seit über 15 Jahren Debian-intern geklärt werden.

marce said:
Nennt sich Version-Pinning. Macht eigentlich niemand, nur Debian, Novell, RedHat und jede andere Distribution, die Release-Basiert arbeitet...

Mir ist das Konzept aus leidiger eigenen Erfahrung durchaus bekannt und ich habe keinerlei Verständniss mehr dafür. Das Konzept war in den 1990ern und früher praktisch und teils sinnvoll, seit den 2000ern jedoch ist es das dümmste Konzept.

(Semi)Rolling-Release ist das einzig sinnvolle und zukunftssichere Konzept, was mitlerweile selbst SUSE, RedHat und auch Microsoft begriffen haben.

Das "Version-Pinning" ermöglicht erst fette Botnets und andere Malware-Schleudern, eben weil öffentlich bekannte (Security)Bugs nicht oder erst nach Jahren gefixt werden.
Hint: Auch wenn ein Bug alleine nicht kritisch zu sein scheint, so ist er in Kombination mit n-1 anderen Bugs eben doch. Und deshalb ist jeder Bug ein potentieller Security-Bug und hat umgehend gefixt zu werden.
Das werden Debianer aber nie verstehen, egal wie häufig sie deshalb auf die Kauleiste fallen.

Fazit: Aktuell ist nur, was Upstream als aktuell bezeichnet und nicht was irgendein Downstream als aktuell betrachtet.

Habe eine Sicherheitslücke im "Server" (Linux) und bräuchte dringend Hilfe.

New Member

Member

Registered User

New Member

Deleted member 15972

Guest

Well-Known Member

Deleted member 15972

Guest

Well-Known Member

New Member

Moderator

New Member

New Member

New Member

Zentrum der Macht

Moderator

Well-Known Member

New Member

Moderator

New Member

Zentrum der Macht

We value your privacy