Magento en de Log4J -kwetsbaarheid
Bijgewerkt 20 december. Dit artikel beschrijft hoe Magento wordt beïnvloed door de kritieke LOG4J -kwetsbaarheid en wat u kunt (en moet) doen om een hack.a kritische kwetsbaarheid in de populaire Log4J Java -bibliotheek te voorkomen, is sinds 1 december enorm geëxploiteerd. Het legt volledige controle bloot aan een externe aanvaller, is gemakkelijk te exploiteren en bijna elk bedrijf dat Java gebruikt, wordt getroffen. Aanvallers hebben in de eerste 48 uur massacanners gelanceerd, terwijl de meeste organisaties moeite hebben om getroffen componenten in hun IT -landschap te vinden. Een andere, maar minder ernstige kwestie werd ontdekt op 14 december. Een derde, maar ook minder kritische kwestie werd ontdekt op december 16e. Het goede nieuws: populaire e -commerceplatforms zoals Magento zijn niet geschreven in Java en zijn op zichzelf niet kwetsbaar. Uw winkel kan echter op Java gebaseerde componenten gebruiken, dus u moet ervoor zorgen dat u deze zo snel mogelijk upgrade, met name: Elasticsearch – versies 6.8.9+, 7,8+ die op Java JDK9+ worden uitgevoerd, lopen geen risico. Oudere ES- of SDK -versies kunnen externe code -uitvoering (ES5) of lekken van servervariabelen mogelijk maken. Om aan de veilige kant te staan, heeft Elasticsearch nieuwe releases verstrekt die het betwiste gedrag uitschakelen. Als u kunt, upgrade naar 6.8.21 of 7.16.1. Verdere analyse hiervan.LogStash – Upgrade 6.8.21 of 7.16.1. Kwetsbaar in combinatie met JDK8 of hieronder. Solr – Upgrade naar 8.11.1.sumo Logic heeft een Java -agent die mogelijk kwetsbaar is (nog niet bevestigd) Sansec heeft een wereldwijde scan van alle Magento -winkels uitgevoerd en vond een handvol winkels die vatbaar leken naar de basisaanvalmethode. Dit is echter geen veiligheidsgarantie voor andere winkels, omdat: uw WAF (zoals CloudFlare, Fastly, Incapsula) onze sondes mogelijk heeft geblokkeerd en aanvallers kunnen deze eerste verdedigingslinie omzeilen. Of uw site is mogelijk al gecompromitteerd en de aanvallers hebben de kwetsbaarheid “vastgesteld” om andere aanvallers buiten te houden. Om de zichtbaarheid van een log4j -fallout te maximaliseren, raden we aan ECOMSCAN in uw winkel aan te maximaliseren. Het zal alle kwetsbare log4j -versies in Java -archieven detecteren en het moet detecteren of er al kwaadaardige activa zijn ingezet. Krijg een volledig functionerende proef met coupon Secure2021 en voer binnen 5 minuten een scan uit. Geloof dat u nu wordt aangevallen? Neem contact met ons op! Ontwikkelingsinstanties: neem contact op als u een massale uitrol van beveiligingsmaatregelen voor al uw klanten wilt doen.
Voorkeursoplossing
Zoek en upgrade kwetsbare log4j -componenten naar versie 2.17 zo snel mogelijk. Als dat op de een of andere manier niet mogelijk is, raadpleegt u de andere secties hieronder voor snelle oplossingen. Om eventuele Java -gebaseerde toepassingen op uw servers te identificeren en te kijken of ze de Log4J -bibliotheek gebruiken, kunt u de nieuwste ECOMSCAN -release gebruiken. Voer het zo uit: eComScan –Key = licentie_key -M0 —MaxSize = 0/Path/to/java/applicatie Als u kwetsbare versies vindt, is de kans groot dat aanvallers al malware op uw systeem hebben geïnjecteerd. U moet uw systeem als aangetast beschouwen. Start een onderzoek van het incidentrespons en gebruik een malware -scanner van de serverzijde om kwaadaardige bestanden en processen te vinden. SANSEC heeft al tal van aanvalsmethoden geïdentificeerd. De primaire vector is het installeren van zombie -agenten op kwetsbare systemen. Deze agenten (ratten) kunnen in een later stadium worden gebruikt om cryptominers, skimmers of ransomware te installeren. We zullen waarschijnlijk de komende weken een stroom gehackte organisaties zien. Update 14 december: Eerste gevallen van ransomware zijn gemeld
Configureer systeemvlag om de kwetsbaarheid uit te schakelen
Als u niet meteen kunt upgraden, hebben vroege gidsen aanbevolen om de JVM -vlag Log4j2.FormatmgnOLookUps = True in te stellen, maar dit beschermt niet tegen alle aanvallen. U moet het implementeren voor het geval dat, maar vertrouw hier niet op.
Magento log4j bescherming met vernis
Fastly heeft een Varnish Log4J -regelset gepubliceerd die alle verzoeken die $ {hebben in inkomende HTTP -headers of postgegevens blokkeert. Dit is zeer effectief, maar ook een zeer ruwe maatregel, omdat het regelmatige (API) oproepen kan blokkeren. We raden aan om deze regels te gebruiken, als: Uw WAF/CDN heeft Log4j beveiligingsregels niet geïmplementeerd. U gebruikt Varnishou U kunt niet upgraden of kwetsbare Log4j-componenten elders upgraden of repareren Strikte broer of zus van https: if (std.strstr (urldecode (req.body), “$ {“) || std.strstr (urldecode (req.http.accept), “$ {“) || std.strstr (urldecode (req.http.accept-additions), “$ {“) || -Charset), “$ {“) || “$ {“) || std.strstr (urldecode (req.http.accept-codering), “$ {“) || | Std.strstr (urldecode (req.http.Accept-Language), “$ {“) || std.strstr (urldecode (req.http.accept-patch), “$ {“) | (req.http.accept-post), “$ {“) || std.strstr (urldecode (req.http.accept-ranges), “$ {“) || -control), “$ {“) || std.strstr (urldecode (req.http.Connection), “$ {“) || std.strstr (urldecode (req.http.content-length), “$ {“) || std.strstr (urldecode (req.http.content-range), “$ {“) || std.strstr (urldecode (req.http.content-type), “$ {“) || std.strstr (urldecode (req.http.cookie), “$ {“) || std.strstr (urldecode (req.http.cookie2), “$ {“) || std.strstr (urldecode (req.http.dnt), “$ {“) || std.strstr (urldecode (req.http.if-gemodificeerd-since), “$ {“) || std.strstr (urldecode (req.http.if-noone-match), “$ {“) || std.strstr (urldecode (req.http.if-range), “$ {“) || std.strstr (urldecode (req.http.Range), “$ {“) || std.strstr (urldecode (req.http.Referer), “$ {“) || std.strstr (urldecode (req.http.referer-root), “$ {“) || std.strstr (urldecode (req.http.sec-fetch-deest), “$ {“) || std.strstr (urldecode (req.http.sec-fetch-mode), “$ {“) || std.strstr (urldecode (req.http.sec-fetch-site), “$ {“) || std.strstr (urldecode (req.http.sec-websocket-accept), “$ {“) || std.strstr (urldecode (req.http.set-cookie), “$ {“) || std.strstr (urldecode (req.http.set-cookie2), “$ {“) || std.strstr (urldecode (req.http.user-agent), “$ {“) || std.strstr (urldecode (req.http.via), “$ {“) || std.strstr (urldecode (req.http.x-content-type-opties), “$ {“) || std.strstr (urldecode (req.http.x-device-accept), “$ {“) || std.strstr (urldecode (req.http.x-device-accept-charet), “$ {“) || std.strstr (urldecode (req.http.x-device-accept-codering), “$ {“) || std.strstr (urldecode (req.http.x-device-accept-taal), “$ {“) || std.strstr (urldecode (req.http.x-device-user-agent), “$ {“) || std.strstr (urldecode (req.http.x-forwarded-for), “$ {“) || std.strstr (urldecode (req.http.x-forwarded-host), “$ {“) || std.strstr (urldecode (req.http.x-forwarded-proto), “$ {“) || std.strstr (urldecode (req.url), “$ {“)) {error 403; }
Magento log4j bescherming met nginx
Als u geen vernis hebt, maar de Nginx -webserver gebruikt, kunt u ook aanvalsverzoeken filteren. U moet echter de LUA -scriptingsmotor laten installeren. Infinirooot deelde een goed voorbeeld: rewrite_by_lua_block {functie decipher (v) lokale s = toString (v) s = ngx.unescape_uri (s) if string.find (s, “$ {base64:”) dan t = (string.gsub ( S, “$ {$ {base64 :([%d%a%=]+)}} “,”%1 “)) s = string.gsub (s,” $ {base64 :([%d%a%=]+)} “, toString (ngx.decode_base64
