Aktuelle Sicherheitslücken

Viper780

Moderator
Er ist tot, Jim!

Registered: Mar 2001
Location: Wien
Posts: 50111

13.12.2021 - 12:16

Privat war bei mir nur der Unifi Controller betroffen.

In der Firma auch der Apache Tomcat - sonst gott sei Dank wenig Java im Einsatz

davebastard

Vinyl-Sammler

Registered: Jun 2002
Location: wean
Posts: 12305

13.12.2021 - 12:20

Zitat aus einem Post von Rektal
Das scheint auch fuer aeltere versionen wie z.b. 5.x gueltig zu sein.

Bin kein java dev und hat mit der Firma Elastic nix am hut, aber wenn man so sieht wie viele applikationen/services davon betroffen sind, wirkt das auf mich als haette da jemand vor langem zur richtigen Zeit an der richtigen Stelle migedacht.

ja wir haben auch noch version 6 da soll heute auch noch ein fix kommen

Viper780

Moderator
Er ist tot, Jim!

Registered: Mar 2001
Location: Wien
Posts: 50111

13.12.2021 - 12:35

Naja die Schwachstelle ist eigentlich eine Fehlarchitektur die 2016 schon bekannt war das JNDI exploitbar ist und man nicht verwenden sollte bzw wenn dann kapseln.

Lord Wyrm

topquote owner since '17

Registered: Jan 2005
Location: wean
Posts: 1326

13.12.2021 - 21:27

Mein Hauptstack war gsd auch nicht betroffen.
vCenter Workaround war in 15min drauf.
Bin gspannt wielange Cisco braucht...

daisho

SHODAN

Registered: Nov 2002
Location: 4C4
Posts: 19731

14.12.2021 - 15:04

Zitat aus einem Post von sichNix
die liste der betroffenen produkte is so grauslich lang, zum glück haben wir nur eins davon im internet, die restlichen 15 die uns in der firma treffen sind zumindest nur intern erreichbar.

https://gist.github.com/SwitHak/b66...b71a8718970c592

Naja, nur weil da was in der Liste ist heißt es ja nicht dass da eine Vulnerability herrscht. Das ist einfach eine Liste an "Hi leute, unser Produkt ...".

Ich schau z.B. auf Veeam (weil halt persönlich im Einsatz): Not affected ... eh klar, kein Java.

Die Kunden zucken komplett aus diesmal scheinbar, war da die Media Coverage so groß oder wegen "10.0" Score?
Bei uns sind 90% der Support Cases derzeit "Hey, gibts da ein Problem log4j2?"

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12083

14.12.2021 - 15:09

Zitat aus einem Post von daisho
Die Kunden zucken komplett aus diesmal scheinbar, war da die Media Coverage so groß oder wegen "10.0" Score?

Die Panik ist durchaus gerechtfertigt. Wenn die RCE-Huerde, die du ueberspringen musst, einfach nur dem Logging-Subsystem deiner Applikation einen einzigen String unterzujubeln ist, dann bist du halt gef*ckt.

nexus_VI

Overnumerousness!

Registered: Aug 2006
Location: südstadt
Posts: 3758

14.12.2021 - 15:14

Wir werden auch laufend um Klarstellungen zum Thema gebeten. Gut, dass wir unseren kompletten Softwarestack selbst kontrollieren.

daisho

SHODAN

Registered: Nov 2002
Location: 4C4
Posts: 19731

14.12.2021 - 15:15

Zitat aus einem Post von COLOSSUS
Die Panik ist durchaus gerechtfertigt. Wenn die RCE-Huerde, die du ueberspringen musst, einfach nur dem Logging-Subsystem deiner Applikation einen einzigen String unterzujubeln ist, dann bist du halt gef*ckt.

Ja sicher, ich finde es nur lächerlich weil die letzten größeren Probleme kaum etwas aufgetaucht ist und bei Heartbleed ist es lang nicht so abgegangen (da war wohl die Sensibilität für Security noch nicht da ...).
Aktuell ist es da ganz schlimm.

Das traurige ist aber eher dass es die Firmen in Wahrheit gar nicht schert bzw. gar keine Ahnung haben was sie in der Regel machen bzw. leider leider leider all zu oft Idioten am Admin-Sessel sitzen die von Tuten und Blasen keine Ahnung haben. Erlebe ich bei Kunden leider nur zu oft.
Die bezahlen tausende und abertausende Euro für Sicherheitsüberprüfungen und die "Lösung" für ein "Euer OpenSSL ist nicht up-2-date"-Problem ist dann (ja, auch schon mitbekommen so ...), "wir drehen HTTPS ab" (also HTTP only, weil dann taucht es nicht mehr am Alert-Schirm auf :bash:

)
> derp

Was ich halt blöd finde ist das jetzt alle schreien und eigentlich nur Gewissheit haben wollen "muss ich was machen?", verstehen tut es aber niemand eigentlich. Merkt man vor allem daran wenn bei Produkten Java überhaupt nicht zum Einsatz kommt und der "erfahrene Admin" trotzdem einen Case aufmacht "wos is los mit log4j"

nexus_VI

Overnumerousness!

Registered: Aug 2006
Location: südstadt
Posts: 3758

14.12.2021 - 15:18

Die Kunden wollen einfach ein Statement, tlw sind das IT-Verantwortliche von größeren Firmen und müssen das intern weitergeben etc. - soll halt verbindlich sein damit sie sich drauf berufen können. Ist eigentlich üblich bei uns, dass der Support dann auch eine Standardantwort parat hat.

Der effektive Umgang mit den "echten" Problemen des täglichen Sysadmin-Lebens ist ja eh jedem selbst überlassen und viel differenzierter zu betrachten.

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12083

14.12.2021 - 15:20

Heartbleed war auch nur ein Information Leak. Das hier ist Remote Code Execution.

Ersteres ist immer mindestens aergerlich, und im schlimmsten Fall eine totale Katastrophe. Letzteres ist immer eine totale Katastrophe (allerspaetestens seit Crypto-Scheisze Ransomware universell salonfaehig gemacht hat).

Das schlimmste Problem in der IT-Branche ist, dass auf den meisten "Admin-Sesseln" Leute sitzen, die in jeder Situation irgendjemanden "vom Support" anrufen koennen wollen, der ihnen genau vorkaut, was zu tun ist. Oder noch besser: der ihnen sagt, das nichts zu tun ist, weil er/sie sich eh (irgendwie) kuemmert. Je mehr Enterprise, desto schlimmer wird's.

Longbow

Here to stay

Registered: Feb 2003
Location: Homeoffice
Posts: 5360

14.12.2021 - 15:23

Zitat aus einem Post von daisho
Ja sicher, ich finde es nur lächerlich weil die letzten größeren Probleme kaum etwas aufgetaucht ist und bei Heartbleed ist es lang nicht so abgegangen (da war wohl die Sensibilität für Security noch nicht da ...).
Aktuell ist es da ganz schlimm.

Das traurige ist aber eher dass es die Firmen in Wahrheit gar nicht schert bzw. gar keine Ahnung haben was sie in der Regel machen bzw. leider leider leider all zu oft Idioten am Admin-Sessel sitzen die von Tuten und Blasen keine Ahnung haben. Erlebe ich bei Kunden leider nur zu oft.
Die bezahlen tausende und abertausende Euro für Sicherheitsüberprüfungen und die "Lösung" für ein "Euer OpenSSL ist nicht up-2-date"-Problem ist dann (ja, auch schon mitbekommen so ...), "wir drehen HTTPS ab" (also HTTP only, weil dann taucht es nicht mehr am Alert-Schirm auf )
> derp

Was ich halt blöd finde ist das jetzt alle schreien und eigentlich nur Gewissheit haben wollen "muss ich was machen?", verstehen tut es aber niemand eigentlich. Merkt man vor allem daran wenn bei Produkten Java überhaupt nicht zum Einsatz kommt und der "erfahrene Admin" trotzdem einen Case aufmacht "wos is los mit log4j"

Dont even get me started...

Ich hab heut 3x das gleiche Gespräch gefürt, dass unsere JavaSCRIPT Node Applikationen "nona" nicht davon betroffen sind und auch die Python Pipelines nicht.

semteX

begehrt die rostschaufel

Registered: Oct 2002
Location: Pre
Posts: 14642

14.12.2021 - 15:26

Zitat aus einem Post von daisho
Was ich halt blöd finde ist das jetzt alle schreien und eigentlich nur Gewissheit haben wollen "muss ich was machen?", verstehen tut es aber niemand eigentlich. Merkt man vor allem daran wenn bei Produkten Java überhaupt nicht zum Einsatz kommt und der "erfahrene Admin" trotzdem einen Case aufmacht "wos is los mit log4j"

du kannst nen server trivial RCEn.. natürlich will ich da von jedem vendor ne zusicherung haben, ob seine software anfällig ist und wenn ja, in wieviel minuten der patch verfügbar is... wie colo schon sagte, das is schlimmer als heartbleed weil die leute sich mit shells auf deinem server ein neues zuhause schaffen. gratulliere, du hast ne remote shell in einer infrastruktur offen. das is so ziemlich der worst case.

sichNix

Here to stay

Registered: Nov 2014
Location: 1230
Posts: 1069

14.12.2021 - 15:36

wenn dein produkt nicht betroffen ist sei doch froh

wir haben zb 9! produkte die es theoretisch betrifft, zum glück alles intern, davon fallen nur 2 raus weil wir uns an die empfohlene konfiguration gehalten haben und eines (veeam

) wo es so zutrifft wie bei dir. mir hat die liste ordentlich zeit erspart das selbst alles zusammen zu suchen.

kleines paradebeispiel wie sowas nicht ablaufen sollte: wir haben einen namhaften zahlungsdienstleister erst drüber informieren müssen (erste info ging am freitag schon raus, am montag mit video weil der first level uns nicht geglaubt hat), die haben erst heute früh gepatched!

Smut

takeover &amp; ether

Registered: Feb 2003
Location: VIE
Posts: 16853

14.12.2021 - 21:07

Zitat aus einem Post von semteX
du kannst nen server trivial RCEn.. natürlich will ich da von jedem vendor ne zusicherung haben, ob seine software anfällig ist und wenn ja, in wieviel minuten der patch verfügbar is... wie colo schon sagte, das is schlimmer als heartbleed weil die leute sich mit shells auf deinem server ein neues zuhause schaffen. gratulliere, du hast ne remote shell in einer infrastruktur offen. das is so ziemlich der worst case.

ist natürlich auch nicht ultimate aber für eine remote shell musst halt auf Architektur verzichtet haben.
da gibts schon noch ein paar schichten die das verhindern.
neben outbound filtering waren WAFs als reaktion am nützlichsten um zeit zu gewinnen.

COLOSSUS

Administrator
GNUltra

Registered: Dec 2000
Location: ~
Posts: 12083

15.12.2021 - 09:27

Zitat aus einem Post von Smut
neben outbound filtering waren WAFs als reaktion am nützlichsten um zeit zu gewinnen.

WAFs sind keine ausreichende Loesung, weil jeder String ja rekursiv zur giftigen JNDI-Ressource (oder wie immer man in JRE-Wahnsinnslingo korrekt dazu sagt) resolved wird. Siehe https://github.com/woodpecker-appst...yload-generator et al.

Viper780 Moderator Er ist tot, Jim! Registered: Mar 2001 Location: Wien Posts: 50111	13.12.2021 - 12:16 Privat war bei mir nur der Unifi Controller betroffen. In der Firma auch der Apache Tomcat - sonst gott sei Dank wenig Java im Einsatz
davebastard Vinyl-Sammler Registered: Jun 2002 Location: wean Posts: 12305	13.12.2021 - 12:20 Zitat aus einem Post von Rektal Das scheint auch fuer aeltere versionen wie z.b. 5.x gueltig zu sein. Bin kein java dev und hat mit der Firma Elastic nix am hut, aber wenn man so sieht wie viele applikationen/services davon betroffen sind, wirkt das auf mich als haette da jemand vor langem zur richtigen Zeit an der richtigen Stelle migedacht. ja wir haben auch noch version 6 da soll heute auch noch ein fix kommen
Viper780 Moderator Er ist tot, Jim! Registered: Mar 2001 Location: Wien Posts: 50111	13.12.2021 - 12:35 Naja die Schwachstelle ist eigentlich eine Fehlarchitektur die 2016 schon bekannt war das JNDI exploitbar ist und man nicht verwenden sollte bzw wenn dann kapseln.
Lord Wyrm topquote owner since '17 Registered: Jan 2005 Location: wean Posts: 1326	13.12.2021 - 21:27 Mein Hauptstack war gsd auch nicht betroffen. vCenter Workaround war in 15min drauf. Bin gspannt wielange Cisco braucht...
daisho SHODAN Registered: Nov 2002 Location: 4C4 Posts: 19731	14.12.2021 - 15:04 Zitat aus einem Post von sichNix die liste der betroffenen produkte is so grauslich lang, zum glück haben wir nur eins davon im internet, die restlichen 15 die uns in der firma treffen sind zumindest nur intern erreichbar. https://gist.github.com/SwitHak/b66...b71a8718970c592 Naja, nur weil da was in der Liste ist heißt es ja nicht dass da eine Vulnerability herrscht. Das ist einfach eine Liste an "Hi leute, unser Produkt ...". Ich schau z.B. auf Veeam (weil halt persönlich im Einsatz): Not affected ... eh klar, kein Java. Die Kunden zucken komplett aus diesmal scheinbar, war da die Media Coverage so groß oder wegen "10.0" Score? Bei uns sind 90% der Support Cases derzeit "Hey, gibts da ein Problem log4j2?"
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12083	14.12.2021 - 15:09 Zitat aus einem Post von daisho Die Kunden zucken komplett aus diesmal scheinbar, war da die Media Coverage so groß oder wegen "10.0" Score? Die Panik ist durchaus gerechtfertigt. Wenn die RCE-Huerde, die du ueberspringen musst, einfach nur dem Logging-Subsystem deiner Applikation einen einzigen String unterzujubeln ist, dann bist du halt gef*ckt.
nexus_VI Overnumerousness! Registered: Aug 2006 Location: südstadt Posts: 3758	14.12.2021 - 15:14 Wir werden auch laufend um Klarstellungen zum Thema gebeten. Gut, dass wir unseren kompletten Softwarestack selbst kontrollieren.
daisho SHODAN Registered: Nov 2002 Location: 4C4 Posts: 19731	14.12.2021 - 15:15 Zitat aus einem Post von COLOSSUS Die Panik ist durchaus gerechtfertigt. Wenn die RCE-Huerde, die du ueberspringen musst, einfach nur dem Logging-Subsystem deiner Applikation einen einzigen String unterzujubeln ist, dann bist du halt gef*ckt. Ja sicher, ich finde es nur lächerlich weil die letzten größeren Probleme kaum etwas aufgetaucht ist und bei Heartbleed ist es lang nicht so abgegangen (da war wohl die Sensibilität für Security noch nicht da ...). Aktuell ist es da ganz schlimm. Das traurige ist aber eher dass es die Firmen in Wahrheit gar nicht schert bzw. gar keine Ahnung haben was sie in der Regel machen bzw. leider leider leider all zu oft Idioten am Admin-Sessel sitzen die von Tuten und Blasen keine Ahnung haben. Erlebe ich bei Kunden leider nur zu oft. Die bezahlen tausende und abertausende Euro für Sicherheitsüberprüfungen und die "Lösung" für ein "Euer OpenSSL ist nicht up-2-date"-Problem ist dann (ja, auch schon mitbekommen so ...), "wir drehen HTTPS ab" (also HTTP only, weil dann taucht es nicht mehr am Alert-Schirm auf ) > derp Was ich halt blöd finde ist das jetzt alle schreien und eigentlich nur Gewissheit haben wollen "muss ich was machen?", verstehen tut es aber niemand eigentlich. Merkt man vor allem daran wenn bei Produkten Java überhaupt nicht zum Einsatz kommt und der "erfahrene Admin" trotzdem einen Case aufmacht "wos is los mit log4j"
nexus_VI Overnumerousness! Registered: Aug 2006 Location: südstadt Posts: 3758	14.12.2021 - 15:18 Die Kunden wollen einfach ein Statement, tlw sind das IT-Verantwortliche von größeren Firmen und müssen das intern weitergeben etc. - soll halt verbindlich sein damit sie sich drauf berufen können. Ist eigentlich üblich bei uns, dass der Support dann auch eine Standardantwort parat hat. Der effektive Umgang mit den "echten" Problemen des täglichen Sysadmin-Lebens ist ja eh jedem selbst überlassen und viel differenzierter zu betrachten.
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12083	14.12.2021 - 15:20 Heartbleed war auch nur ein Information Leak. Das hier ist Remote Code Execution. Ersteres ist immer mindestens aergerlich, und im schlimmsten Fall eine totale Katastrophe. Letzteres ist immer eine totale Katastrophe (allerspaetestens seit Crypto-Scheisze Ransomware universell salonfaehig gemacht hat). Das schlimmste Problem in der IT-Branche ist, dass auf den meisten "Admin-Sesseln" Leute sitzen, die in jeder Situation irgendjemanden "vom Support" anrufen koennen wollen, der ihnen genau vorkaut, was zu tun ist. Oder noch besser: der ihnen sagt, das nichts zu tun ist, weil er/sie sich eh (irgendwie) kuemmert. Je mehr Enterprise, desto schlimmer wird's.
Longbow Here to stay Registered: Feb 2003 Location: Homeoffice Posts: 5360	14.12.2021 - 15:23 Zitat aus einem Post von daisho Ja sicher, ich finde es nur lächerlich weil die letzten größeren Probleme kaum etwas aufgetaucht ist und bei Heartbleed ist es lang nicht so abgegangen (da war wohl die Sensibilität für Security noch nicht da ...). Aktuell ist es da ganz schlimm. Das traurige ist aber eher dass es die Firmen in Wahrheit gar nicht schert bzw. gar keine Ahnung haben was sie in der Regel machen bzw. leider leider leider all zu oft Idioten am Admin-Sessel sitzen die von Tuten und Blasen keine Ahnung haben. Erlebe ich bei Kunden leider nur zu oft. Die bezahlen tausende und abertausende Euro für Sicherheitsüberprüfungen und die "Lösung" für ein "Euer OpenSSL ist nicht up-2-date"-Problem ist dann (ja, auch schon mitbekommen so ...), "wir drehen HTTPS ab" (also HTTP only, weil dann taucht es nicht mehr am Alert-Schirm auf ) > derp Was ich halt blöd finde ist das jetzt alle schreien und eigentlich nur Gewissheit haben wollen "muss ich was machen?", verstehen tut es aber niemand eigentlich. Merkt man vor allem daran wenn bei Produkten Java überhaupt nicht zum Einsatz kommt und der "erfahrene Admin" trotzdem einen Case aufmacht "wos is los mit log4j" Dont even get me started... Ich hab heut 3x das gleiche Gespräch gefürt, dass unsere JavaSCRIPT Node Applikationen "nona" nicht davon betroffen sind und auch die Python Pipelines nicht.
semteX begehrt die rostschaufel Registered: Oct 2002 Location: Pre Posts: 14642	14.12.2021 - 15:26 Zitat aus einem Post von daisho Was ich halt blöd finde ist das jetzt alle schreien und eigentlich nur Gewissheit haben wollen "muss ich was machen?", verstehen tut es aber niemand eigentlich. Merkt man vor allem daran wenn bei Produkten Java überhaupt nicht zum Einsatz kommt und der "erfahrene Admin" trotzdem einen Case aufmacht "wos is los mit log4j" du kannst nen server trivial RCEn.. natürlich will ich da von jedem vendor ne zusicherung haben, ob seine software anfällig ist und wenn ja, in wieviel minuten der patch verfügbar is... wie colo schon sagte, das is schlimmer als heartbleed weil die leute sich mit shells auf deinem server ein neues zuhause schaffen. gratulliere, du hast ne remote shell in einer infrastruktur offen. das is so ziemlich der worst case.
sichNix Here to stay Registered: Nov 2014 Location: 1230 Posts: 1069	14.12.2021 - 15:36 wenn dein produkt nicht betroffen ist sei doch froh wir haben zb 9! produkte die es theoretisch betrifft, zum glück alles intern, davon fallen nur 2 raus weil wir uns an die empfohlene konfiguration gehalten haben und eines (veeam ) wo es so zutrifft wie bei dir. mir hat die liste ordentlich zeit erspart das selbst alles zusammen zu suchen. kleines paradebeispiel wie sowas nicht ablaufen sollte: wir haben einen namhaften zahlungsdienstleister erst drüber informieren müssen (erste info ging am freitag schon raus, am montag mit video weil der first level uns nicht geglaubt hat), die haben erst heute früh gepatched!
Smut takeover &amp; ether Registered: Feb 2003 Location: VIE Posts: 16853	14.12.2021 - 21:07 Zitat aus einem Post von semteX du kannst nen server trivial RCEn.. natürlich will ich da von jedem vendor ne zusicherung haben, ob seine software anfällig ist und wenn ja, in wieviel minuten der patch verfügbar is... wie colo schon sagte, das is schlimmer als heartbleed weil die leute sich mit shells auf deinem server ein neues zuhause schaffen. gratulliere, du hast ne remote shell in einer infrastruktur offen. das is so ziemlich der worst case. ist natürlich auch nicht ultimate aber für eine remote shell musst halt auf Architektur verzichtet haben. da gibts schon noch ein paar schichten die das verhindern. neben outbound filtering waren WAFs als reaktion am nützlichsten um zeit zu gewinnen.
COLOSSUS Administrator GNUltra Registered: Dec 2000 Location: ~ Posts: 12083	15.12.2021 - 09:27 Zitat aus einem Post von Smut neben outbound filtering waren WAFs als reaktion am nützlichsten um zeit zu gewinnen. WAFs sind keine ausreichende Loesung, weil jeder String ja rekursiv zur giftigen JNDI-Ressource (oder wie immer man in JRE-Wahnsinnslingo korrekt dazu sagt) resolved wird. Siehe https://github.com/woodpecker-appst...yload-generator et al.

Aktuelle Sicherheitslücken

Forum Index > Software > Applications, Apps & Drivers

Viper780

davebastard

Viper780

Lord Wyrm

daisho

COLOSSUS

nexus_VI

daisho

nexus_VI

COLOSSUS

Longbow

semteX

sichNix

Smut

COLOSSUS