Magento en de Log4j-kwetsbaarheid
Bijgewerkt op 20 december. Dit artikel beschrijft hoe Magento wordt getroffen door de kritieke log4j-kwetsbaarheid en wat u kunt (en moet) doen om een hack te voorkomen. Een kritieke kwetsbaarheid in de populaire Log4j Java-bibliotheek wordt sinds 1 december massaal uitgebuit. Het geeft volledige controle aan een aanvaller op afstand, is gemakkelijk te misbruiken en bijna elk bedrijf dat Java gebruikt, wordt getroffen. Aanvallers hebben in de eerste 48 uur massale scanners gelanceerd, terwijl de meeste organisaties moeite hebben om getroffen componenten in hun IT-landschap te vinden. Een ander, maar minder ernstig probleem werd op 14 december ontdekt. Een derde, maar ook minder kritiek probleem werd op 14 december ontdekt. 16. Het goede nieuws: populaire e-commerceplatforms zoals Magento zijn niet in Java geschreven en zijn op zichzelf niet kwetsbaar. Uw winkel kan echter Java-gebaseerde componenten gebruiken, dus zorg ervoor dat u deze zo snel mogelijk upgradet, in het bijzonder: ElasticSearch – versies 6.8.9+, 7.8+ die draaien op Java JDK9+ lopen GEEN risico. Oudere ES- of SDK-versies kunnen uitvoering van externe code (ES5) of het lekken van servervariabelen mogelijk maken. Voor de zekerheid heeft ElasticSearch nieuwe releases uitgebracht die het betwiste gedrag uitschakelen. Upgrade indien mogelijk 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 lager. Solr – upgrade naar 8.11.1. Sumo Logic heeft een Java-agent die mogelijk kwetsbaar is (nog niet bevestigd) Sansec heeft een wereldwijde scan uitgevoerd van alle Magento-winkels en een handvol winkels gevonden die kwetsbaar leken naar de basisaanvalmethode. Dit is echter geen veiligheidsgarantie voor andere winkels, omdat: Uw WAF (zoals Cloudflare, Fastly, Incapsula) mogelijk onze sondes heeft geblokkeerd en aanvallers mogelijk deze eerste verdedigingslinie kunnen omzeilen. Of uw site is mogelijk al gecompromitteerd en de aanvallers hebben de kwetsbaarheid “gerepareerd” om andere aanvallers buiten te houden. Om de zichtbaarheid van eventuele log4j-uitval te maximaliseren, raden we u aan om eComscan in uw winkel uit te voeren. Het zal alle kwetsbare log4j-versies in Java-archieven detecteren en zou moeten detecteren of er al kwaadaardige middelen zijn ingezet. Ontvang een volledig functionerende proefversie met coupon SECURE2021 en voer binnen 5 minuten een scan uit. Gelooft u dat u nu wordt aangevallen? Neem contact met ons op!Ontwikkelingsbureaus: neem contact op als u een massale uitrol van beveiligingsmaatregelen voor al uw klanten wilt doen.
Voorkeursoplossing
Vind en upgrade kwetsbare log4j-componenten zo snel mogelijk naar versie 2.17. Als dat op de een of andere manier niet mogelijk is, raadpleeg dan de andere secties hieronder voor snelle oplossingen. Om op Java gebaseerde applicaties op uw servers te identificeren en te zien of ze de Log4j-bibliotheek gebruiken, kunt u de nieuwste eComscan-release gebruiken. Voer het als volgt uit:ecomscan –key=LICENSE_KEY -m0 –maxsize=0 /path/to/java/application Als u kwetsbare versies aantreft, is de kans groot dat aanvallers al malware op uw systeem hebben geïnjecteerd. U moet uw systeem als gecompromitteerd beschouwen. Start een incidentresponsonderzoek en gebruik een malwarescanner op de server om kwaadaardige bestanden en processen te vinden. Sansec heeft al talloze aanvalsmethoden geïdentificeerd. De primaire vector is het installeren van zombieagenten op kwetsbare systemen. Deze agenten (RAT’s) kunnen in een later stadium worden gebruikt om cryptominers, skimmers of ransomware te installeren. De komende weken zullen we waarschijnlijk een stortvloed aan gehackte organisaties zien. Update 14 december: eerste gevallen van ransomware zijn gemeld
Configureer de systeemvlag om het beveiligingslek uit te schakelen
Als u niet meteen kunt upgraden, raden vroege handleidingen aan om de JVM-vlag log4j2.formatMsgNoLookups=true in te stellen, maar dit biedt geen bescherming tegen alle aanvallen. U moet het voor de zekerheid implementeren, maar vertrouw hier niet op.
Magento log4j-bescherming met vernis
Fastly heeft een Varnish log4j-regelset gepubliceerd die alle verzoeken met ${ in inkomende HTTP-headers of POST-gegevens blokkeert. Dit is zeer effectief, maar ook een zeer grove maatregel, omdat het reguliere (API-) oproepen kan blokkeren. We raden u aan deze regels te gebruiken als: uw WAF/CDN geen log4j-beveiligingsregels heeft geïmplementeerd u Varnish gebruikt u kwetsbare log4j-componenten niet elders kunt upgraden of repareren# Apache Log4j2 <=2.14.1 JNDI RCE - CVE-2021-44228 # Dit is een meer 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), "${") || std.strstr(urldecode(req.http.accept-ch), "${") || std.strstr(urldecode(req.http.accept -charset), "${") || std.strstr(urldecode(req.http.accept-ch-lifetime), "${") || std.strstr(urldecode(req.http.accept-datetime), "${") || std.strstr(urldecode(req.http.accept-encoding), "${") || std.strstr(urldecode(req.http.accept-features), "${") | | std.strstr(urldecode(req.http.accept-taal), "${") || std.strstr(urldecode(req.http.accept-patch), "${") || std.strstr(urldecode (req.http.accept-post), "${") || std.strstr(urldecode(req.http.accept-ranges), "${") || std.strstr(urldecode(req.http.cache -controle), "${") || 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-sinds), "${") || std.strstr(urldecode(req.http.if-none-match), "${") || std.strstr(urldecode(req.http.if-bereik), "${") || 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-dest), "${") || 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-options), "${") || std.strstr(urldecode(req.http.x-apparaat-accepteren), "${") || std.strstr(urldecode(req.http.x-device-accept-charset), "${") || std.strstr(urldecode(req.http.x-device-accept-encoding), "${") || std.strstr(urldecode(req.http.x-device-accept-taal), "${") || std.strstr(urldecode(req.http.x-apparaat-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), "${") ) { fout 403; }
Magento log4j-bescherming met Nginx
Als u geen Varnish heeft maar de Nginx-webserver gebruikt, kunt u ook aanvalsverzoeken filteren. U moet echter wel de LUA-scripting-engine geïnstalleerd hebben. Infiniroot deelde een goed voorbeeld: rewrite_by_lua_block { function decipher(v) local s = tostring(v) s=ngx.unescape_uri(s) if string.find(s, “${base64:”) then t=(string.gsub( s, “${${basis64:([%d%a%=]+)}}”, “%1”)) s=string.gsub(s, “${base64:([%d%a%=]+)}”, tostring(ngx.decode_base64
