[Vermutlich gelöst] Dropbear-Quellen natürlich nicht kompromittiert

[JohnDoe42]

Hallo zusammen,

seit ca. dem 22.03.2014 finde ich in zwei meiner Boxen, welche einen DynDNS-Account benutzen, permament folgende Einträge in den Logs:

Apr  3 01:26:49 fritz kern.warn kernel: [1432204.810000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=78.142.63.63 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=88 ID=5381 DF PROTO=TCP SPT=80 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  3 01:27:28 fritz kern.warn kernel: [1432243.980000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=78.142.63.63 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=118 ID=27096 DF PROTO=TCP SPT=80 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  3 01:28:43 fritz user.notice ONLINECHANGED[7376]: [offline] approved
Apr  3 01:28:43 fritz user.notice ONLINECHANGED[7376]: [offline] executing /etc/onlinechanged/00-get_ip
Apr  3 01:28:43 fritz user.notice ONLINECHANGED[7376]: [offline] executing /etc/onlinechanged/vsftpd
Apr  3 01:28:43 fritz user.notice ONLINECHANGED[7376]: [offline] finished
Apr  3 01:28:44 fritz user.notice ONLINECHANGED[7392]: [online] approved
Apr  3 01:28:44 fritz user.notice ONLINECHANGED[7392]: [online] executing /etc/onlinechanged/00-get_ip
Apr  3 01:28:44 fritz user.notice ONLINECHANGED[7392]: [online] executing /etc/onlinechanged/vsftpd
Apr  3 01:28:44 fritz user.notice ONLINECHANGED[7392]: [online] finished
Apr  3 01:29:01 fritz kern.warn kernel: [1432336.860000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=78.142.63.63 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=107 ID=12316 DF PROTO=TCP SPT=80 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  3 01:29:05 fritz kern.warn kernel: [1432340.660000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=78.142.63.63 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=114 ID=18321 DF PROTO=TCP SPT=80 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0

Apr  2 01:17:21 fritz kern.warn kernel: [1345236.990000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.74 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=123 ID=10440 DF PROTO=TCP SPT=17879 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  2 01:19:26 fritz kern.warn kernel: [1345361.600000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.74 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=80 ID=26531 DF PROTO=TCP SPT=31119 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  2 01:20:01 fritz cron.info crond[20090]: crond: USER root pid 18754 cmd /etc/init.d/rc.rrdstats backup
Apr  2 01:28:34 fritz kern.warn kernel: [1345910.550000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.74 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=112 ID=11262 DF PROTO=TCP SPT=33312 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  2 01:29:45 fritz user.notice ONLINECHANGED[19066]: [offline] approved
Apr  2 01:29:45 fritz user.notice ONLINECHANGED[19066]: [offline] executing /etc/onlinechanged/00-get_ip
Apr  2 01:29:45 fritz user.notice ONLINECHANGED[19066]: [offline] executing /etc/onlinechanged/vsftpd
Apr  2 01:29:45 fritz user.notice ONLINECHANGED[19066]: [offline] finished
Apr  2 01:29:46 fritz user.notice ONLINECHANGED[19082]: [online] approved
Apr  2 01:29:46 fritz user.notice ONLINECHANGED[19082]: [online] executing /etc/onlinechanged/00-get_ip
Apr  2 01:29:46 fritz user.notice ONLINECHANGED[19082]: [online] executing /etc/onlinechanged/vsftpd
Apr  2 01:29:46 fritz user.notice ONLINECHANGED[19082]: [online] finished
Apr  2 01:36:09 fritz kern.warn kernel: [1346364.790000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.74 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=87 ID=20871 DF PROTO=TCP SPT=56025 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  2 01:40:01 fritz cron.info crond[20090]: crond: USER root pid 19400 cmd /etc/init.d/rc.rrdstats backup
Apr  2 01:44:56 fritz kern.warn kernel: [1346891.890000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.74 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=97 ID=26898 DF PROTO=TCP SPT=32634 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  2 01:51:10 fritz kern.warn kernel: [1347265.700000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.74 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=100 ID=16302 DF PROTO=TCP SPT=26692 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  2 01:58:02 fritz kern.warn kernel: [1347677.730000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.74 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=91 ID=42960 DF PROTO=TCP SPT=17971 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  2 01:58:39 fritz kern.warn kernel: [1347714.710000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.74 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=114 ID=60152 DF PROTO=TCP SPT=12780 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0

Also wird von ein und derselben IP versucht, auf den auf der Box befindlichen Dropbear-Server zu verbinden. Das Kuriosum liegt darin, daß die Versuche auch nach einem erfolgten IP-Wechsel stattfinden ...daraus schließe ich, daß nicht die IP-Adresse zum Loginversuch verwendet wird, sondern der DynDNS-Name der Box. Und diesen benutze ich ja traditionell zum Login ...
Folglich hatte ich die Befürchtung, daß diese meine Login-Daten irgendwo ausgespät wurden.
Ich verbinde mich auf die Boxen nur von zwei anderen Maschinen aus, jede dieser habe ich auf einen Befall des wohl aktuell umgehenden Ebury-Rootkits hin untersucht - beide sind sauber. Dies habe ich getan, weil bspw. die zweite IP auch bei anderen aufgetaucht ist.
Nun meine Frage: Wenn ich die zwei Maschinen, von denen ich mich verbinde, ausschließen kann - könnte es evtl. sein, daß die Dropbear-Quellen, aus denen den Server gabut wird, nicht integer sind ? Mir ist bewußt, daß das wahrscheinlich Unsinn ist, aber ich mir fällt leider keine weitere Erklärung für obiges Phänomen ein ...
Ratlose Grüße,

JD.

 

[koyaanisqatsi]

Moin

Teste und beobachte...

...ob solche Verbindungsversuche weiterhin stattfinden wenn du den Standardport 22 auf meinetwegen 22222 änderst.

 

[JohnDoe42]

Den Tip lese ich öfter mal ....
Allerdings führt er dazu, daß ich den Standard-Port für SSH, für den die eine oder andere Firewall durchlässig ist, nicht mehr nutzen kann ...
Und eigentlich wollte ich nicht wissen, wie ich die Versuche abwehre (das klappt schon), sondern wie sie zustande kommen ...

 

[koyaanisqatsi]

Vermutlich sind das irgendwelche Bots, die IP Ranges auf die Standardports "abgrasen".
Allerdings kann ich dir aufgrund von fehlenden Wissen/Erfahrung nicht schreiben wonach du im Quelltext von dropbear
mal suchen solltest. Wenn der Sourcecode tatsächlich kompromitiert sein sollte.

Meine Erfahrung zeigt aber, dass die Benutzung von Standardports, auch im lokalen Netz, nicht als sicher gelten kann.
Ich halte es inzwischen so: Keine Standardports mehr, wo es geht.
Wenn ich im Web surfe, benutze ich einen Proxy im Browser der lokale Adressen filtert.
Dann kommt auch keine kompromitierende Webseite an lokale Adressen und IPs.
Man weiss ja Heutzutage nicht mehr, wo wann welches HTML

<img src="169.254.1.1:22" alt="Guten Tag"></img>

Mein lokales Netz auf irgendetwas antestet.
Dafür nutz ich tinyproxy mit solchen regulären Ausdrücken...

fritz.[a-z]{2,4}
deep[a-z]{1,99}
open[a-z]{1,99}
snom[a-z]{1,99}
epso[a-z]{1,99}
busy[a-z]{1,99}
dark[a-z]{1,99}
sams[a-z]{1,99}
[h,f]{1,1}[t]{1,2}[p]{1,1}[s]{0,1}[:]{1,1}[/]{2,2}[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}

...das hilft, sichert vor Angriffen von "innen".

 

[JohnDoe42]

Was mich an der Sache irritiert, war/ist, daß die Verbindungsversuche offensichtlich den IP-Wechsel überleben, also der Angreifer bereits nach einigen Sekunden die neue IP weiß (oder halt den DynDNS-Namen).
Daraus würde ich ableiten, daß das keine Bots sein können, die Ranges abgrasen. Denn dann würden sie dies vermutlich nach einem algebraischen Muster tun (123.45.67.003 nach 123.45.67.002) usw.

 

[koyaanisqatsi]

Das ist wirklich schwer zu sagen wie das Zustande kommt.
Richtig übel, wäre es zum Beispiel, wenn der DNS-Server spioniert.
Der könnte jede Abfrage an einen "Spion" weiterleiten.
Aber, das weisst du, und ich auch, gehört zu den Verschwörungstheorien.

 

[JohnDoe42]

Ich habe nochmal ein wenig recherchiert:

Hier und hier gibt es weitere Informationen zu einer der IPs .....
Möglicherweise sollte ich doch noch mal einen Virenscanner auf den Rechnern im Netz der Box laufen lassen ...

 

[koyaanisqatsi]

Wie jetzt?
Noch nicht erledigt?
Die Zeiten sind nämlich vorbei, wo man im Betrieb des Rechners irgendwelche verdächtigen Aktivitäten an Ressourcenmangel,
oder ständiges rattern der Festplatte/n erkennen konnte.

Viel Glück.

 

[RalfFriedl]

Hast Du denn schon mal überprüft, ob Du tatsächlich eine neue IP-Adresse bekommst? Und selbst wenn die Adresse anders ist, ist sie vom gleichen Provider und vermutlich immer noch in der Nähe der ursprünglichen Adresse.
Speziell im zweiten Auszug sieht man, dass auch nach dem Wechsel der IP Adresse alle paar Minuten eine Verbindung versucht wird. Ich gehe mal davon aus, dass diese Versuche nicht nur nachts kurz vor und nach der Trennung stattfinden, sondern den ganzen Tag über. Wenn dort also kontinuierlich die Adressen durch probiert werden und alle paar Minuten wieder von vorne angefangen wird, dann ist Deine Adresse immer wieder mal dabei, ob die alte oder die neue.

Was die Vermutung mit den Quellen des dropbear Servers betrifft, weiß der SSH Server denn überhaupt, unter welchem Namen er ansprechbar ist?

 

[vice_pres]

Und es können natürlich auch Bots sein. Die gibts auch schon seit Jahren nicht nur für IP-Adressen sondern auch für Domains, gerade für dyn-provider. Da werden bekannte Adressen probiert und zusätzlich "Wörterbuch"-basiert nach weiteren Subdomains gesucht die Antworten. Meine persönliche Meinung: Ich denke kompromittierte Dropbear Quellen wären schon ordentlich aufgefallen.

@Ralf: Das müsste doch relativ einfach sein. Entweder meldet er sich direkt an einem Server mit nem Lebenszeichen in Form von einem Datenpaket oder benutzt eins der vielen wie-ist-meine-ip scripte und reportet dann die Adresse.

 

[JohnDoe42]

Hast Du denn schon mal überprüft, ob Du tatsächlich eine neue IP-Adresse bekommst?

Ja.

Ich gehe mal davon aus, dass diese Versuche nicht nur nachts kurz vor und nach der Trennung stattfinden, sondern den ganzen Tag über.

Korrekt, das tun sie.

Wenn dort also kontinuierlich die Adressen durch probiert werden und alle paar Minuten wieder von vorne angefangen wird, dann ist Deine Adresse immer wieder mal dabei, ob die alte oder die neue.

Nehmen wir als Rechengrundlage mal Folgendes an: Von meinem (DSL-)Provider bekomme ich in 95 Prozent der Fälle eine IP-Adresse von drei Knotenpunkten in unserer Gegend aus drei /15-Netzen. Das sind alleine einige hunderttausend IPs. Dazu kommen noch ein paar andere Provider mit mindestens gleich großen Netzen landesweit, ich würde schätzen einige zehn Mios. Wie hoch ist die Wahrscheinlichkeit, daß, wie im ersten Beispiel, innerhalb von anderthalb Minuten der Besucher wieder da ist ?

@ vice_pres:
Die Sache mit den Wörterbuch-Subdomains von bekannten DynDNS-Providern hatte ich mir auch schon überlegt .... alice.dyndns-remote.com, bob.dyndns-remote.com usw.
Das könnte man vermeiden, indem man stattdessen (8Md%1^k.dyndns-remote.com verwenden würde .....
Ich warte den Virenscan ab und werde wieder berichten.

 

[koyaanisqatsi]

Sorry, kann sein das es nervt, trotzdem, stellt euch mal vor, die Bots benutzen Google...

site:*.dyndns.*
Ungefähr 738.000 Ergebnisse

site:*.no-ip.*
Ungefähr 910.000 Ergebnisse
(scheinen viele Chinesen zu nutzen)

Das wären dann Treffer für Port 80 und 443.
Die jetzt mal auf Port 22 checken....
usw usw

Aber, dafür ist Google auch da, für die, die gefunden werden wollen.

 

[JohnDoe42]

So, kleines Update:

Alle Rechner im Netz der betreffenden Box sind virenfrei.
Ich hatte für die Box desweiteren mal testweise ein anderes DynDNS-Konto erzeugt. Danach verschwanden die Angriffe der zweiten IP kurz - aber eben nur bis gestern bzw. heute. Aktuell laufen diese unverändert weiter:

Apr  4 09:26:04 fritz kern.warn kernel: [1547360.400000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.103 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=105 ID=23619 DF PROTO=TCP SPT=10725 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  4 09:27:52 fritz kern.warn kernel: [1547467.630000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.103 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=91 ID=22092 DF PROTO=TCP SPT=40259 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  4 09:29:46 fritz kern.warn kernel: [1547581.960000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.103 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=93 ID=50939 DF PROTO=TCP SPT=3361 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  4 09:32:52 fritz kern.warn kernel: [1547768.520000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.103 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=122 ID=41045 DF PROTO=TCP SPT=42139 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 
Apr  4 09:33:30 fritz kern.warn kernel: [1547805.760000] [IPT] DENY-FRITZ-ACCESS IN=dsl OUT= MAC= SRC=186.2.161.103 DST=192.168.1.1 LEN=52 TOS=0x00 PREC=0x00 TTL=89 ID=32039 DF PROTO=TCP SPT=47915 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0

Das heißt, daß der DynDNS-Name der Box vermutlich keine Rolle spielt.
Wenn ich mir desweiteren die Zeitspanne zwischen den einzelnen Versuchen so anschaue (einige Minuten), halte ich doch eher die Brute-force-Theorie für wahrscheinlich (da vermutlich niemand so dämlich sein dürfte, seine Treffer-Statistik künstlich mit waits zu verschlechtern). Zumal diese Versuche scheinbar nur in Netzen vom größten nationalen Anbieter vonstatten gehen.
Ich beobachte noch ein bischen und setze das Thema prophylaktisch auf "Gelöst".
Grüße,

JD.

Edit: Hier ist die IP auch schon aufgetaucht ...