News regreSSHion: Millionen Linux-Systeme von OpenSSH-LĂŒcke bedroht
- Ersteller Kaito Kariheddo
- Erstellt am
- Zur News: regreSSHion: Millionen Linux-Systeme von OpenSSH-LĂŒcke bedroht
areiland
Admiral
- Registriert
- Apr. 2010
- BeitrÀge
- 8.223
Laut News betrifft diese LĂŒcke aber OpenSSH Server, nicht den Clienten. Und fĂŒr mich bedeutet das, dass ich meinen Raspi mit Octoprint ĂŒberprĂŒfen muss. Auch wenn der nicht von aussen zugĂ€nglich ist, sicher ist einfach sicher.Hamburg schrieb:
JustAnotherTux
Lt. Commander
- Registriert
- Dez. 2010
- BeitrÀge
- 1.785
Viele CVEs sind kein Beleg dafĂŒr das etwas weniger sicher ist.nutrix schrieb:
FOSS wird viel mehr untersucht als closed source einfach weil es sich besser untersuchen lÀsst.
Von daher halte ich die Frequenz und die Anzahl der gefundenen CVEs nicht fĂŒr einen Beleg dafĂŒr, das Software A weniger sicher ist als Software B mit weniger CVEs.
Vermutlich hat auch FreeBSD weniger CVEs als Linux aber auch das bedeutet nicht viel schlieĂlich wird FreeBSD auch deutlich weniger verwendet.
Zuletzt bearbeitet:
Also "so gut wie alles" ist aber auch ĂŒbertrieben.Helge01 schrieb:
In deinem Auszug von einer Stunde mit zwei HĂ€nden voll Ports und dann noch von verschiedenen Sources, die vom Namen her nix miteinander zu tun haben...
Bei angenommen 10 Ports pro Stunde und IP sind das 272 Tage um einmal die ganze 655xx Portrange zu scannen. Pro IP! Wir haben bspw. pro Standort mehrere 24Bit v4 Netze. Bei /22 wĂ€ren das 763 Jahre fĂŒr die 1024 IPs.
So lÀuft das in aller Regel nicht. Was meistens gescannt wird sind standard Ports bzw. known Ports. Also bekannte Dienste mit ihren genutzten Ports. Darunter auch sowas wie 8080, 8443, 8888 oder andere HighPorts. Nen Fullscan, wo Jemand wirklich die ganze Latte durchscannt finde ich bei mir in den Logs in aller Regel nicht. Das kommt vereinzelt mal in abgeschwÀchter Form vor, aber selbst dann nicht voll.
Das wĂŒrde bedeuten, du gewichtest die Wartezeit auf Patches ĂŒber alle anderen Paramenter. MMn ist das vom Ansatz her Kokolores.blackiwid schrieb:
Es mag ein Teil der Thematik sein, aber bei weitem keine wirklich hoch gewichtete. Es spielt keine Rolle wie lange es dauert, bis Patches released werden. Sondern es spielt nur eine Rolle, wie lange ein potentieller Angreifer von einer LĂŒcke wusste und die Seite, die Patches liefert, es nicht tat.
Nö, das ist auch quatsch. Man kann die zwei Dinge nicht miteinander vergleichen. Vor allem da in so einem Einzeiler schlicht keinerlei Dinge definiert sind und die Basis out of the Box drastisch unterschiedlich ist.blackiwid schrieb:
Was definiert hier "sicher"? Sicher in was? Sicher bei was? Sicher vor was? In aller erster Line hĂ€ngt Sicherheit von der durch den User gemachten Konfiguration ab. Streiten kann man sich sicher ĂŒber default Settings. Aber wenn man ehrlich ist - Unwissenheit schĂŒtzt vor Strafe nicht. Das gilt auch fĂŒr IT.
Nicht wird. Es kann alles gescannt werden. Aber wirklich hÀufig kommt das bspw. nicht vor.up.whatever schrieb:
Kleiner Vergleich. Ich hab gerade mal fĂŒr den Monat Juni 2024 geschaut was auf einem unserer Mail Gateways im Log auftaucht. Absichtlich dieses, weil die IP im Netz bekannt ist und gerade auch die Maildomain ĂŒberall zu finden ist, was mit uns zu tun hat. Sprich die IP ist fĂŒr jeden der nur paar Sekunden investiert, findbar.
1002 dstport="3306"
1097 dstport="8088"
1135 dstport="8291"
1148 dstport="8888"
1198 dstport="8443"
1244 dstport="7547"
1683 dstport="995"
1829 dstport="53"
1845 dstport="143"
1929 dstport="139"
1931 dstport="993"
2161 dstport="2222"
2292 dstport="1433"
2541 dstport="8080"
2606 dstport="8081"
3292 dstport="3389"
3683 dstport="22"
3807 dstport="6379"
4090 dstport="110"
4615 dstport="443"
4683 dstport="445"
5473 dstport="80"
6068 dstport="8728"
17125 dstport="23"
Das ist Aufsteigend sortiert die Anzahl der FW Hits auf der einen IP.
Im ganzen Monat lag der total uniq Hitcount bei 50770 (von 65535) Dabei sind lediglich 24 Ports bei gröĂer 1000 Hits. In Summe 78477 von in Summe 318154 totalen Hits. Was fast ein viertel ist.
HeiĂt - ein viertel der Scanversuche dieses Monats geht auf 24 Ports.
Ja entweder gezielt oder halt ĂŒber Umwege. Was halt oft versucht wird sind known Angriffsvektoren. Es gibt eine Menge dieser Scan Maschinen, die dann eben die Daten speichern und wo sich im Zweifel Angreifer von bedienen.metoer schrieb:
Ansich ist der Ressourcenbedarf relativ ĂŒberschaubar. Kommt halt drauf an, was man am Ende wirklich machen möchte. Das passiert beim Scan eh gestaffelt. Also erst relativ "seicht" schauen ob ĂŒberhaupt was antwortet. Also prĂŒfen ist die IP erreichbar. Wenn ja, wird geschaut welche Ports. In manchen FĂ€llen geht es dann halt auch tiefer hinein.
Dem ist so. Siehe oben, man kann sicher ĂŒber default Settings streiten. Aber am Ende ist das kein echter Garant fĂŒr Sicherheit, weil man eben im Zweifel die Settings entsprechend eindreht und gut ist.nutrix schrieb:
Und noch weiter gedacht - je nachdem was gemeldet wird, handelt es sich dabei um Module/Zusatzkomponenten, die man natĂŒrlich auch erstmal nutzen muss.JustAnotherTux schrieb:
Ein Vergleich zu Windows ist dabei sogar auch relativ schwer, weil sich der Umfang unterscheidet. Ist eine LĂŒcke in Notepad jetzt eine LĂŒcke in Windows? Oder nicht? Weil in Linux wĂ€re vi, vim oder nano eben nicht Linux.
maxpayne80
Commander
- Registriert
- Nov. 2006
- BeitrÀge
- 2.332
Y-Chromosome schrieb:
Kurze Frage dazu:
setzt man es auf 0 dann kann man sich praktisch nicht mehr per SSH einloggen, weil das Zeitfenster zwischen Verbindungsaufbau und erfolgreicher Authentifizierung auf 0 gesetzt wird?
Ich vermute etwas zu ĂŒbersehen, aber bisher keine eindeutigen Informationen gefunden
D
Donnidonis
Gast
Er lÀsst sich eine Liste geben mit allen offenen SSH Ports und geht sie durch, wenn du dabei bist, hast Pech gehabt.metoer schrieb:
homer0815
Ensign
- Registriert
- Juni 2021
- BeitrÀge
- 180
@Donnidonis Oder einfach nmap starten und die Telekom IP-Range nach 22 TCP abscannen.
Die Racecondition braucht wohl auf 32bit an die 8h bis sie zum Erfolg fĂŒhrt. Bei 64bit eine Woche. Zumindest die 64bit Server sollten bis dahin bei einem seriösen Betreiber schon gepatcht werden. Wir haben gestern 250 Suse Server gepatcht.
Will damit aber nicht behaupten, das mein Arbeitgeber seriös ist ;-)
Die Racecondition braucht wohl auf 32bit an die 8h bis sie zum Erfolg fĂŒhrt. Bei 64bit eine Woche. Zumindest die 64bit Server sollten bis dahin bei einem seriösen Betreiber schon gepatcht werden. Wir haben gestern 250 Suse Server gepatcht.
Will damit aber nicht behaupten, das mein Arbeitgeber seriös ist ;-)
- Registriert
- Mai 2007
- BeitrÀge
- 5.004
Das absolut nicht - alleine, weil MS z.b. sicher sehr viele gefundene LĂŒcken gar nicht public macht, sondern still und leise patched.JustAnotherTux schrieb:
Was in Bezug auf CVEs aber eine Aussagekraft hat ist, wie damit umgegangen wird. Also Dinge wie Reaktionsgeschwindigkeit, Patch-VerfĂŒgbarkeit und -QualitĂ€t, Kommunikation usw.
Und in der Hinsicht gibt es leider oftmals kaum schlechtere Beispiele als MS.
Pampersbomber
Ensign
- Registriert
- Juni 2010
- BeitrÀge
- 226
BestÀtigt meine Vorsicht, keinen SSH Port Richtung Internet aufzumachen.
Bei einer meiner Cloud VMs ist daher SSH nur ĂŒber eine Wireguard Verbindung möglich.
Bei einer meiner Cloud VMs ist daher SSH nur ĂŒber eine Wireguard Verbindung möglich.
lynx007
Commodore
- Registriert
- Feb. 2011
- BeitrÀge
- 4.811
mike78sbg schrieb:
Das soll 'nen Race Conditions Problem bei der Authentifizierung sein! Sprich deine TĂŒr bugt, weil der Einbrecher gleichzeitig die "klingel" und die "klinge" drĂŒckt...., und zwar im exakt falschen Moment und Reihenfolge, dadurch wird das Schloss ĂŒberschrieben, mit dem Code vom Angreifer". Zumindest in der Theorie âŠ
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt
Alles andere kommt danach! Wie ein SNES Glitch, wo 2 Tasten gleichzeitig drĂŒckt, und dann durch die wand, fĂ€llst! Der eine Prozesse ĂŒberschreibt den anderen, weil Sie zeitgleich, oder in einem Zeitfenster simultan passieren! TĂŒr ist offen.... ! Da bringt dein Key nichts.... den fĂŒr 'nen Key brauchst du 'nen Schloss.... aber wen das weg ist âŠ
Ganz ins Detail habe ich mich noch nicht eingelesen ⊠Nur wen das Schloss ĂŒberschreibe, dann bringt dein bester schlĂŒssel nichts! Und wen man sich dann das Rating und die Vektoren ansieht.... das Ding hat sich ohne Grund eine 8.9 ! Aber es ist auch nicht 10, und nicht einfach umsetztbar... es darf nicht BSD, nicht 64 bit sein und noch kein Update haben.... und dauert son angriff gute 4-8 std. ...
https://blog.qualys.com/vulnerabili...ode-execution-vulnerability-in-openssh-server
ErgÀnzung ()
Oder du machst hatl den fix... du brauchst ja nur in die config gehen scheinbar...Pampersbomber schrieb:
Zuletzt bearbeitet:
Ich habe jetzt nicht alle Kommentare gelesen, aber im Artikel wird nicht so ganz erklĂ€rt, warum die LĂŒcke wieder aufgetaucht ist. Wie ist es eigentlich möglich, ein gepatches Problem wieder einzufĂŒhren? Den ursprĂŒnglichen Code hat man ja wahrscheinlich nicht wieder reingeschrieben.
Pampersbomber
Ensign
- Registriert
- Juni 2010
- BeitrÀge
- 226
Und dann warte ich auf die nÀchste Schwachstelle. Nope, da bleibe ich lieber bei SSH via Wireguard (mit PSK).lynx007 schrieb:
ZugegebenermaĂen könnte Wireguard auch Schwachstellen haben. Aber weil der Code auf wenige Seiten Papier passen wĂŒrde, vertraue ich darauf, dass die AngriffsflĂ€che immer kleiner sein wird, als die eines Featuremonsters wie OpenSSH.
eastcoast_pete
Lt. Commander
- Registriert
- Juni 2020
- BeitrÀge
- 1.666
Per se ist kein System, das von auĂen zugĂ€nglich ist, sicher. Bei Linux sind schwerwiegende Angriffe zwar selten, dafĂŒr aber potentiell besonders lohnend, da die groĂe Mehrheit der Server mit der einen oder anderen Version von Linux unterwegs ist. Holzauge sei wachsam ist nie verkehrt, egal welches OS man nutzt.nutrix schrieb:Wie war das nochmal mit der Behauptung "Linux sei per se sicherer"?
Man muĂ sich nur mal tĂ€glich die CVE Meldungen fĂŒr reinziehen, da wird es einem ganz anders.
D
Data_x33
Gast
Richtig. Mit der Option bleibt ĂŒberhaupt keine Zeit, sich anzumelden. Wie soll man sich denn damit anmelden können? Vielleicht kann ja der Tippgeber mehr dazu sagen.maxpayne80 schrieb:
Keylan
Lt. Commander
- Registriert
- Apr. 2012
- BeitrÀge
- 1.512
@GFdeb12 @maxpayne80 Wie bei nahezu jeder Statusvariable die ein Limit definiert bedeutet 0, das kein Limit gilt. In dem Fall lÀsst sich der Exploit nicht mehr ausnutzen, da dieser ja grade versucht beim Timeout des Verbindungsaufbaus einen bestimmen Memory-Overflow zu erzeugen.
Die bisherigen Infos kamen im Kontext eines 2 Minuten Timeouts auf einem 32-Bit System. Bei 64-Bit Systemen ist die Wahrscheinlichkeit den erwĂŒnschten Overflow zu erzeugen massiv geringer und bei lĂ€ngerem Timeout erhöht sich der Zeitaufwand je Verbindungsversuch linear zum Timeout.
Genau konnte das unter den Laborbedingungen noch gar nicht mit so einem System nachgestellt werden (nur auf 32-Bit in einer VM, also mit optimalen Netzwerkverbindungen). Deshalb die SchĂ€tzungen das die Attacken auf 64-Bit Server, oder solche mit lĂ€ngeren Timeouts (600 Sekunden sind nicht unĂŒblich) mehrere Tage bis Wochen dauern wĂŒrden um Aussicht auf einen erfolgreichen Zugriff haben.
Relevante Ziele sind damit ohnehin nur dauerhaft vom Internet erreichbare Server, welche auch bekannte offenen SSH Ports haben und keinerlei MaĂnahmen um ĂŒbliche Netzwerkangriffe abzuwehren (z.B. fail2ban).
Schon wenn der Angreifer die Ports nicht kennt, oder um weitere Abwehrmechanismen herum agieren muss vervielfacht sich die notwendige Zeit fĂŒr einen Angriff schnell zu unrealistischen Werten.
Die bisherigen Infos kamen im Kontext eines 2 Minuten Timeouts auf einem 32-Bit System. Bei 64-Bit Systemen ist die Wahrscheinlichkeit den erwĂŒnschten Overflow zu erzeugen massiv geringer und bei lĂ€ngerem Timeout erhöht sich der Zeitaufwand je Verbindungsversuch linear zum Timeout.
Genau konnte das unter den Laborbedingungen noch gar nicht mit so einem System nachgestellt werden (nur auf 32-Bit in einer VM, also mit optimalen Netzwerkverbindungen). Deshalb die SchĂ€tzungen das die Attacken auf 64-Bit Server, oder solche mit lĂ€ngeren Timeouts (600 Sekunden sind nicht unĂŒblich) mehrere Tage bis Wochen dauern wĂŒrden um Aussicht auf einen erfolgreichen Zugriff haben.
Relevante Ziele sind damit ohnehin nur dauerhaft vom Internet erreichbare Server, welche auch bekannte offenen SSH Ports haben und keinerlei MaĂnahmen um ĂŒbliche Netzwerkangriffe abzuwehren (z.B. fail2ban).
Schon wenn der Angreifer die Ports nicht kennt, oder um weitere Abwehrmechanismen herum agieren muss vervielfacht sich die notwendige Zeit fĂŒr einen Angriff schnell zu unrealistischen Werten.
Zuletzt bearbeitet:
- Registriert
- Nov. 2007
- BeitrÀge
- 509
Stecke nicht so tief in der Materie drin, aber sollte nicht z.B. ein korrekt konfiguriertes fail2ban als Schutz ausgereicht haben? AuĂer der Angreifer verteilt seine Login-Versuche ĂŒber zig verschiedene IPs.
Muss mich dann glaub ich doch nochmal ĂŒber weitere security-Mechanismen schlau machen. Port knocking liest sich ja ganz gut.
Muss mich dann glaub ich doch nochmal ĂŒber weitere security-Mechanismen schlau machen. Port knocking liest sich ja ganz gut.
