Sunny61 816 Geschrieben 14. Dezember 2021 Melden Geschrieben 14. Dezember 2021 (bearbeitet) @cj_berlin Du warst zu schnell. ;) bearbeitet 14. Dezember 2021 von Sunny61 Zitieren
zahni 566 Geschrieben 14. Dezember 2021 Melden Geschrieben 14. Dezember 2021 (bearbeitet) Der neuste Shit ist 2.16 Die Einschränkung auf bestimmte Java-Versionen wurde entfernt. https://www.heise.de/news/Log4j-2-16-0-verbessert-Schutz-vor-Log4Shell-Luecke-6294053.html bearbeitet 14. Dezember 2021 von zahni Zitieren
phatair 39 Geschrieben 14. Dezember 2021 Melden Geschrieben 14. Dezember 2021 Hier eine gute Übersicht von Tools, Infos und zB. bekannten IPs https://github.com/NCSC-NL/log4shell Eine Frage habe ich aber noch, da man darüber immer unterschiedliche Infos liest. Laut BSI ist ja die Lücke auch nutzbar, ohne das Schadcode nachgeladen wird. Bei uns haben so gut wie keine Server Internet Zugriff. Vor allem die Server in der DMZ haben das nicht. 2 Server in der DMZ nutzen tatsächlich Log4j. Einer konnte schon gepatched werden, der andere ist leider wichtig für den Unternehmensbetrieb und wurde so gut wie möglich isoliert. Er ist aber nicht per HTTP oder HTTPS von Extern erreichbar, was hoffentlich dazu führt, dass er noch nicht angegriffen wurde. Ist man etwas "sicherer" wenn die Server eben kein nachladen von Code ermöglichen oder spielt das tatsächlich keine Rolle? Ich lese immer wieder, dass über den String jndi:ldap:// der Angriff erfolgt und das würde doch bedeuten dass über den externen LDAP Server der Code nachgeladen werden muss. Zitieren
magicpeter 12 Geschrieben 14. Dezember 2021 Melden Geschrieben 14. Dezember 2021 vor 8 Stunden schrieb cj_berlin: IGEL UMS: https://kb.igel.com/securitysafety/en/isn-2021-11-ums-log4j-vulnerability-54086712.html Danke, habe ich sofort durchgeführt... Hat jemand schon einen guten Scanner gefunden den man auf seinen Windows Server einmal laufen lassen kann um zu schauen ob der Spaß auf dem Server installiert ist. Scanner https://github.com/logpresso/CVE-2021-44228-Scanner Zitieren
daabm 1.386 Geschrieben 14. Dezember 2021 Melden Geschrieben 14. Dezember 2021 vor 5 Stunden schrieb phatair: Ich lese immer wieder, dass über den String jndi:ldap:// der Angriff erfolgt und das würde doch bedeuten dass über den externen LDAP Server der Code nachgeladen werden muss. Dem würde ich vorsichtig zustimmen. War auch die Meinung unserer OpSec-Profis - Server, die nicht rauskönnen, sind kaum angreifbar. Und "nicht raus" schließt bei uns nicht nur das Internet ein - unser RZ ist komplett segmentiert, da kann keiner auf irgendeinem Port mit "irgendwem" reden, wenn das nicht vorgesehen ist. LDAP (389) z.B. nur zu den LDAP-Servern (DCs oder ODSEE) im jeweiligen Realm. Wenn das weniger restriktiv ist, wird's schwierig - ein LDAP-Server ist ja aus einem Office-Makro schnell mal gestartet... Und der steht dann im internen Netz, schickt seinen Attack-String an betroffene Ziele. jm2c Zitieren
MurdocX 965 Geschrieben 15. Dezember 2021 Melden Geschrieben 15. Dezember 2021 Zitat Telefonanlage Starface: Aussage des Supports: Auch die STARFACE setzt in der Telefonanlage auf diese Bibliothek, aber auf eine NICHT betroffene Version. Zitieren
NorbertFe 2.155 Geschrieben 14. Januar 2022 Autor Melden Geschrieben 14. Januar 2022 Am 13.12.2021 um 14:52 schrieb NorbertFe: Ich bin aktuell selbst noch auf der Suche nach einer Aussage von APC/Schneider Electric, falls also jemand was weiß, gern her damit. Egal ob Patch, Workaround oder "gar nicht betroffen". :) https://www.se.com/ww/en/download/document/SESB-2021-347-01/ So, toll nur "Würgherum" mit manuellem Gefrickel, anstatt einfach eine bereinigte Version bereitzustellen. :/ Zitieren
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.