Nginx Alias traversal હજુ પણ ઘણા પ્રોજેક્ટ્સ માટે એક જટિલ સમસ્યા છે
તાજેતરમાં સમાચારોએ તે તોડી નાખી કેટલાક nginx સર્વર્સ હજુ પણ સંવેદનશીલ છે તકનીક "Nginx ઉપનામ ટ્રાવર્સલ», જે 2018 માં બ્લેકહાટ કોન્ફરન્સમાં પ્રસ્તાવિત કરવામાં આવી હતી અને ઉપનામ નિર્દેશિકામાં ઉલ્લેખિત રૂટ ડિરેક્ટરીની બહાર સ્થિત ફાઇલો અને ડિરેક્ટરીઓને ઍક્સેસ કરવાની મંજૂરી આપે છે.
સમસ્યાનો સાર તે છે બ્લોક્સ માટે ફાઇલો ઉપનામ નિર્દેશ સાથે વિનંતી કરેલ પાથ જોડીને પ્રદાન કરવામાં આવે છે, તેને સ્થાન નિર્દેશનના માસ્ક સાથે મેચ કર્યા પછી અને આ માસ્કમાં ઉલ્લેખિત પાથના ભાગને કાપી નાખ્યા પછી.
સમસ્યા દેખાય છે ફક્ત "ઉર્ફે" નિર્દેશ સાથે રૂપરેખાંકનોમાં, Nginx રૂપરેખાંકનની જેમ, 'લોકેશન' નામનો એક નિર્દેશ છે જે વર્ણવી શકે છે કે ચોક્કસ URL ની ઍક્સેસ કેવી રીતે હેન્ડલ કરવી જોઈએ, અને તેનો ઉપયોગ સર્વર પરની ફાઇલોને URL સોંપવા માટે થાય છે.
ઉપનામ સાથે સંયોજનમાં આ સ્થાનનો ઉપયોગ કરતી પેટર્નમાં, જ્યારે 'સ્થાન દ્વારા ઉલ્લેખિત URL ના અંતે સ્લેશ ન મૂકશો' અને 'નિર્દિષ્ટ પાથના અંતે સ્લેશ મૂકો' ની બે શરતો મહત્વપૂર્ણ છે. ઉપનામ દ્વારા' મળ્યા છે. ઉપનામ ' મળ્યા છે. નબળાઈ આવી કહેવાય.
BlackHat 2018 કોન્ફરન્સમાં, Orange Tsai એ બ્રેકિંગ URL પાર્સર્સ પર તેમનું સંશોધન રજૂ કર્યું. અન્ય પ્રભાવશાળી શોધોમાં, તેણે @iaklis દ્વારા બનાવવામાં આવેલ 2016 HCTF CTF ચેલેન્જમાં શોધાયેલ ટેકનિકનું નિદર્શન કર્યું.
તકનીકને લાગુ કરવા માટે, નીચેની શરતો પૂરી કરવી આવશ્યક છે:
સ્થાન નિર્દેશનમાં તેના પાથમાં ફોરવર્ડ સ્લેશ ન હોવો જોઈએ;
ઉપનામ ડાયરેક્ટિવ સ્થાન સંદર્ભમાં હાજર હોવું જોઈએ અને ફોરવર્ડ સ્લેશ સાથે સમાપ્ત થવું જોઈએ.
ઉપર દર્શાવેલ સંવેદનશીલ રૂપરેખાંકનના ઉદાહરણ માટે, હુમલાખોર "/img../test.txt" ફાઇલની વિનંતી કરી શકે છે અને આ વિનંતી સ્થાન "/img" માં ઉલ્લેખિત માસ્ક સાથે મેળ ખાશે, જે પછી કતાર બાકી છે ". ./test.txt" ઉપનામ નિર્દેશક પાથ "/var/images/" સાથે જોડવામાં આવશે અને પરિણામે "/var/images/../test.txt" ફાઇલની વિનંતી કરવામાં આવશે.
તેથી, હુમલાખોરો "/var/images/" માંની ફાઇલોને જ નહીં, "/var" ડિરેક્ટરીમાં કોઈપણ ફાઇલને ઍક્સેસ કરી શકે છે, ઉદાહરણ તરીકે, nginx લોગ ડાઉનલોડ કરવા માટે, તમે વિનંતી મોકલી શકો છો "/img ../log/nginx /access.log”.
વિશ્લેષણ GitHub પર રીપોઝીટરીઝમાંથી દર્શાવે છે કે nginx રૂપરેખાંકનમાં ભૂલો જે સમસ્યા તરફ દોરી જાય છે તે હજી પણ વાસ્તવિક પ્રોજેક્ટ્સમાં છે.
ઉદાહરણ તરીકે, બિટવર્ડન પાસવર્ડ મેનેજર બેકએન્ડમાં સમસ્યા જોવા મળી હતી અને તેનો ઉપયોગ /etc/bitwarden ડિરેક્ટરીમાંની બધી ફાઈલોને એક્સેસ કરવા માટે થઈ શકે છે (/etc/bitwarden/ attachments/ માંથી /atchments માટેની વિનંતીઓ જારી કરવામાં આવી હતી), જેમાં સંગ્રહિત ડેટાબેઝનો સમાવેશ થાય છે. પાસવર્ડ્સ "vault.db", પ્રમાણપત્ર અને લૉગ્સ સાથે, જેના માટે તે "vault.db", "identity.pfx", "api.log", વગેરે વિનંતીઓ મોકલવા માટે પૂરતું હતું.
તેવો ઉલ્લેખ છે આ નબળાઈની તીવ્રતા પ્રોજેક્ટના આધારે નોંધપાત્ર રીતે વધઘટ થઈ શકે છે, નજીવી અસરથી ગંભીર સુધી. તેની અસરની મર્યાદા મુખ્યત્વે તેના દ્વારા નક્કી કરવામાં આવે છે કે શું ખુલ્લી નિર્દેશિકામાં સંવેદનશીલ ડેટા છે જે વધુ હુમલાઓને સરળ બનાવી શકે છે અથવા ખાનગી માહિતીના ખુલાસામાં પરિણમી શકે છે.
આ નબળાઈ માટે અમારી શોધના પ્રારંભિક બિંદુ તરીકે, અમે લોકપ્રિય GitHub ભંડારનું અન્વેષણ કરવાનું પસંદ કર્યું છે જે આ સમસ્યા દર્શાવે છે. સ્ત્રોત કોડની ઍક્સેસ સાથેના વાતાવરણમાં આ ચોક્કસ નબળાઈને ઓળખવી નોંધપાત્ર રીતે વધુ શક્ય બને છે, મુખ્યત્વે બે મુખ્ય પરિબળોને કારણે:
તપાસ - સરળ કોડ વિશ્લેષણ સાધનોનો ઉપયોગ કરીને, જેમ કે નિયમિત અભિવ્યક્તિ શોધ, અમને આ પ્રોજેક્ટ્સની અંદર સંભવિત રૂપે સંવેદનશીલ Nginx રૂપરેખાંકન ફાઇલોને અસરકારક રીતે ઓળખવા દે છે.
શોષણ: ચોક્કસ લક્ષ્ય નિર્દેશિકાને જાણવું કે જેને ઉપનામ સોંપવામાં આવ્યું છે તે અમને સ્થાનિક દાખલો સેટ કરવા, સ્થાનિક શેલનો ઉપયોગ કરીને ઉપનામિત ડિરેક્ટરીઓની તપાસ કરવા અને નબળાઈ દ્વારા કઈ ફાઇલોને ઍક્સેસ કરી શકાય તે નિર્ધારિત કરવાની મંજૂરી આપે છે.
ઉલ્લેખનીય છે કે આ પદ્ધતિ Google HPC ટૂલકિટ સાથે પણ કામ કરતી હતી, જ્યાં વિનંતીઓને ખાનગી કી અને ઓળખપત્રો સાથે ડેટાબેઝ મેળવવા માટે રસની ડિરેક્ટરીમાં રીડાયરેક્ટ કરવામાં આવતી હતી, હુમલાખોર "secret_key" અને "db.sqlite3" ક્વેરીઝ મોકલી શકે છે.
છેલ્લે, જો તમને તેના વિશે વધુ જાણવામાં રસ હોય, તો તમે વિગતોનો સંપર્ક કરી શકો છો નીચેની કડીમાં