Sunny61 806 Geschrieben 14. Dezember 2021 Melden Teilen Geschrieben 14. Dezember 2021 (bearbeitet) @cj_berlin Du warst zu schnell. ;) bearbeitet 14. Dezember 2021 von Sunny61 Zitieren Link zu diesem Kommentar
zahni 554 Geschrieben 14. Dezember 2021 Melden Teilen 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 Link zu diesem Kommentar
phatair 39 Geschrieben 14. Dezember 2021 Melden Teilen 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 Link zu diesem Kommentar
magicpeter 11 Geschrieben 14. Dezember 2021 Melden Teilen 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 Link zu diesem Kommentar
daabm 1.356 Geschrieben 14. Dezember 2021 Melden Teilen 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 Link zu diesem Kommentar
MurdocX 952 Geschrieben 15. Dezember 2021 Melden Teilen 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 Link zu diesem Kommentar
NorbertFe 2.045 Geschrieben 14. Januar 2022 Autor Melden Teilen 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 Link zu diesem Kommentar
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.