Allvarligt säkerhetshål gör miljontals enheter sårbara

Sitter och patchar, trallallallalaaa ...

Nackdelen med att använda delade packet, visst det sparar mycket tid och så men det kan skapa globala problem som i detta fall.

Suck, jag är ju en av de drabbade då alla mina webbapplikationer nyttjar just log4j. Så det är uppdaterat och klart just nu. Tyvärr så körde jag en uppgradering på en debian-server som låg lite efter och vips så gick en kundapplikation sönder pga NÅNTING. Så jag får spendera morgondagen med att debugga vad tusan som gör att den inte kan skriva tumnagels-bilder mot en disk som den ju kunde fint igår. Uppgraderingar är inte alltid av godo... (problemetär löst nu)

Att notera är att log4J 1.2 inte är drabbat! (Om man inte använder JMS-appenders) Detta kom ju ut explicit på log4j:s hemsida först idag tror jag. Så jag kan tro att det är rätt många som uppdaterat äldre applikationer med från 1.2.x till 2.0.16 bara för att vara säker. Det innebär kod- och konfigurationsändringar som inte är helt triviala då 2.0 inte är bakåtkompatibel. Att patcha upp en applikation från 2.x till senaste 2.0.16 som nu rekommenderas är ju mycket enklare.

Uppdatering. log4J 1.2 har en tidigare CVE som nyttjar en SocketServer att deserialisera malign kod. Min bedömning är dock att för att den ska kunna nyttjas måste den port den använder öppnas i brandväggen. För att vara helt säker ska man dock uppgradera log4j till 2.0.16...

Precis ovanför ditt inlägg har du ett...

Indeed. Och hur mycket skulle då affärsidén att ägna sig åt kommersiell hackerversamhet vara värd? Hacking skulle gå tillbaka att bli ett problem för kontraspionaget.

Mycket möjligt om den koden är Javabaserad.

Att servern kör Apache som frontend är ingen ovanlighet för webbapplikationer i Java. Den anropar i sin tur ett antal servrar i backend som då kör Java, typ Tomcat. Den funkar alltså som en proxy som bara vidarebefordrar anropen och svaren. Apache ger inget skydd för detta alls m.a.o.

Nja, beror väl på hur du definierar unika. Det kommer garanterat finnas ett relativt litet antal vanliga fel. Det är bara att pröva de vanligaste misstagen så kommer du snabbt hitta massor av sårbara servrar. Sedan är det då enormt mycket mer arbete att fixa alla dessa buggarna.
Jag skulle hävda att kommersiellt hackande hade blivit mer lönsamt då du iprincip hade kunnat automatisera processen att hitta sårbara servrar.

Det kan de ju göra men det beror först och främst på om de använder Java-mjukvara, och sedan då om denna mjukvara använder log4j (väldigt vanligt), och i så fall vilken version av log4j.

Java är väl inte särskilt vanligt i de allra "minsta" / mest inbäddade prylarna men för t.ex. en NAS eller liknande är det ju definitivt inte uteslutet (särskilt vad gäller något slags "appar"/tillägg).

Just det där låter som en potentiell missuppfattning. "Köra Apache" är väldigt otydligt, men jag skulle gissa att den som säger det pratar om Apache httpd, men detta problem har absolut inget med Apache httpd att göra.

Detta är ett problem i Java-biblioteket log4j, också från Apache Software Foundation, som är extremt vanligt att det används i alla möjliga *Java-applikationer*.

Men själva Apache-biten i båda fallen är alltså bara organisationen som står bakom. Apache httpd är inte skrivet i Java och kan därmed inte ens använda log4j.

https://thehackernews.com/2021/12/second-log4j-vulnerability-... suck...

Exakt så, om alla hade skrivit 100% av all kod så skulle antalet hål ökas exponentiellt jämfört med hur det är idag. Det är ju tack vare att log4j är delat som just det hålet har hittats och sedan fixats så att alla som använder dels blivit informerade om det och dels fått tillgång till fixen.

Hade det istället funnits fel i en hemmasnickrad logg så hade du dels inte fått info om det utan du skulle behöva hoppas att du på något vis skulle upptäcka att någon utnyttjar detta hål i din mjukvara på dina maskiner och du skulle sedan tvingas att komma på fixen själv.

Visst, man hade inte kunnat köra ett stort script för att hitta alla sårbara servrar som kör log4j som script-kiddsen kör just nu, men det är å andra sidan inte de som är den stora farliga marknaden inom hacking heller, plus att vart ska man dra gränsen för vad man ska skriva själva? Snart är man ju nere på att man måste bygga sin egen CPU, sitt eget OS, sina egna drivrutiner, sin egen kompiler, sitt eget programmeringsspråk osv osv.

Extensive på så vis att den testar mycket, men allt ingår i samma test. Mata skriptet med din adress så sköter den resten (Y)

Tror inte alls ett sådant verktyg är fulltäckande. Många servrar kör ju custom mjukvara eller ett företags egna produkter. Denna typ av verktyg analyserar kanske bara vanliga tjänster som apache webservrar eller letar efter andra kända produkter och versioner med kända fel

De kommer inte testa att injecta dålig kod på anslutningar som kräver inloggning eller andra saker heller...

Se detta som ett verktyg i en låda, ibland hjälper det, men man måste använda många verktyg för att slutföra ett specifikt jobb

Är givetvis säkrare att lita på leverantör. Jag kan tänka mig att de kanske använder log4j för annat än web?

Som ovan skriver, svårt att vara heltäckande.

Testverktyget verkar angripa tjänsten för att se vad som händer, ja.
Men den kanske inte nödvändigtvis gör det på rätt sätt för just den givna tjänsten, dvs en tjänst kan exponera log4shell-sårbarheten på något annat sätt än vad verktyget testar.

Just det verktyget verkar ju dessutom vara begränsat till HTTP, så andra typer av tjänster kan den nog inte testa alls.

Finns en 6.5.55 nu oxå
https://community.ui.com/releases/UniFi-Network-Application-6...

Ja, det där verkar ju vara en rätt grundlig sammanställning och åtminstone de delarna som ansluter till vad som uppmärksammats nu verkar ju stämma bra, så jag tror ju iaf inte att det är något hittepå där i.

Just perspektivet att det inte verkar ha varit avsikten från personen som bidrog med funktionen för jndi-lookup att den skulle kunna användas i message lookups, och förmodligen inte heller från de som valde att ta in koden, är väl förmodligen nyckeln till hur det kunde bli som det blev. (Eventuellt helt omedvetna om att message lookups är en grej.)

Message lookups i sig verkar ju ha tillkommit i ett tidigt skede som en tveksam lösning på ett problem och som sedan skavt lite men varit mestadels harmlöst, åtminstone fram tills dess att jndi-funktionaliteten lades till. Ovilja att bryta kompatibiliteten för något som ter sig harmlöst är väl förmodligen vad man ska läsa in i att message lookups blev kvar trots att det skavde lite ibland.