સતત એકીકરણ અને સતત જમાવટ (CI/CD) pipelineસુવ્યવસ્થિત સોફ્ટવેર વિકાસને સરળ બનાવવામાં મુખ્ય ભૂમિકા ભજવે છે. છતાં, આ pipelineજોખમો વધુને વધુ મહત્વપૂર્ણ બનતા જાય છે, તેમને નબળાઈઓથી બચાવવાની આવશ્યકતા વધુ સ્પષ્ટ થતી જાય છે. આ ઊંડાણપૂર્વકની તપાસ OWASP ટોપ-10 માં ઓળખાયેલા એક મુખ્ય જોખમને સંબોધવા પર ધ્યાન કેન્દ્રિત કરે છે. CI/CD સુરક્ષા જોખમો: ઝેર Pipeline અમલ (PPE).
ઝેર શું છે? Pipeline અમલ (PPE)
OWASP ટોપ-10 મુજબ CI/CD સુરક્ષા જોખમો, "ઝેર Pipeline અમલ (પી.પી.ઈ.) જોખમ એ હુમલાખોરની ક્ષમતાનો ઉલ્લેખ કરે છે જેની પાસે સોર્સ કંટ્રોલ સિસ્ટમ્સની ઍક્સેસ હોય - અને બિલ્ડ પર્યાવરણની ઍક્સેસ વિના - બિલ્ડમાં દૂષિત કોડ/આદેશો દાખલ કરીને બિલ્ડ પ્રક્રિયામાં ફેરફાર કરવા માટે pipeline રૂપરેખાંકન, મૂળભૂત રીતે 'ઝેર' આપવું pipeline અને બિલ્ડ પ્રક્રિયાના ભાગ રૂપે દૂષિત કોડ ચલાવવો"
થોડા શબ્દોમાં કહીએ તો, ઝેરી Pipeline એક્ઝેક્યુશન (PPE) ત્યારે ઉત્પન્ન થાય છે જ્યારે હુમલાખોર ફેરફાર કરી શકે છે pipeline તર્ક.
બે છે ચલો:
- ડાયરેક્ટ પીપીઈ (ડી-પીપીઇ): D-PPE પરિસ્થિતિમાં, હુમલાખોર CI રૂપરેખા ફાઇલમાં ફેરફાર કરે છે રિપોઝીટરીમાં તેઓ ઍક્સેસ કરી શકે છે, કાં તો ફેરફારને સીધા રેપો પર અસુરક્ષિત દૂરસ્થ શાખામાં ધકેલીને, અથવા શાખા અથવા ફોર્કમાંથી ફેરફાર સાથે PR સબમિટ કરીને. સીઆઈ હોવાથી pipeline એક્ઝેક્યુશનને સંશોધિત CI રૂપરેખાંકન ફાઇલમાંના આદેશો દ્વારા વ્યાખ્યાયિત કરવામાં આવે છે, હુમલાખોરના દૂષિત આદેશો આખરે બિલ્ડ નોડમાં બિલ્ડ થયા પછી ચાલે છે. pipeline ટ્રિગર થયેલ છે.
- પરોક્ષ PPE (આઇ-પીપીઇ): અમુક કિસ્સાઓમાં, D-PPE ની શક્યતા એવા વિરોધી માટે ઉપલબ્ધ નથી જેની પાસે SCM ભંડાર (દા.ત. જો pipeline એ જ રીપોઝીટરીમાં અલગ, સુરક્ષિત શાખામાંથી CI રૂપરેખાંકન ફાઇલ ખેંચવા માટે ગોઠવેલ છે). આવી સ્થિતિમાં, ઝેર આપવાને બદલે pipeline પોતે જ, હુમલાખોર દ્વારા સંદર્ભિત ફાઇલોમાં દૂષિત કોડ દાખલ કરે છે pipeline (ઉદાહરણ તરીકે: ની અંદરથી સંદર્ભિત સ્ક્રિપ્ટો pipeline રૂપરેખાંકન ફાઇલ)
બંને કિસ્સાઓમાં, GitHub સંશોધિતને અમલમાં મૂકશે pipeline અગાઉની સમીક્ષા કે મંજૂરીની જરૂર વગર.
PPE ની વહેલી શોધ
આપણે આ પ્રકારની નબળાઈ કેવી રીતે શોધી શકીએ?
ચાલો આ ઉદાહરણ જોઈએ. pipeline :
અને ડમી શેલ સ્ક્રિપ્ટ (runtests.sh) ની સામગ્રી:
આ pipeline એકદમ સરળ છે: તેનો ઉદ્દેશ્ય સમીક્ષકને કેટલાક પ્રારંભિક સંકેતો આપવાનો છે Pull Request (PR) સ્વીકૃતિ પ્રક્રિયા:
- તે 'આ' ના રોજ ટ્રિગર થશે પુલ_રિક્વેસ્ટ (એટલે કે જ્યારે પણ PR બનાવવામાં આવે છે)
- તે PR કોડ (એટલે કે ફાળો આપેલ કોડ) ચેકઆઉટ કરે છે.
- તે બિલ્ડ બનાવશે
- તે ફાળો આપેલ કોડ પર પરીક્ષણો ચલાવશે (દા.ત. શેલ સ્ક્રિપ્ટ ચલાવીને)
જો કોડ કમ્પાઇલ ન થાય અથવા તે પરીક્ષણો પાસ કરવામાં નિષ્ફળ જાય તો પગલાં #3 (બિલ્ડ બનાવો) અને #4 (પરીક્ષણ ચલાવો) નિષ્ફળ જશે. તેથી, આ પગલાં PR સ્વીકારવા માટે જરૂરી, પરંતુ પૂરતા નથી, શરત તરીકે કાર્ય કરે છે. જો સફળ થાય, તો રેપો એડમિન ફાળો આપેલા કોડની સમીક્ષા કરવા માટે આગળ વધશે અને તેના આધારે, તે PR સ્વીકારશે/અસ્વીકાર કરશે/ટિપ્પણી કરશે.
ઝાયજેની સ્કેનર
ઝીગેની CLI પૂરું પાડે છે ("ઝાયજેની સ્કેનર”) જે a માં એમ્બેડ કરી શકાય છે pipeline અથવા કમાન્ડ-લાઇનમાં ચલાવો. ઝીજેની સ્કેનર પ્રક્રિયા કરશે pipelineનબળાઈઓ તપાસવા માટે અને, જો GitHub PAT આપવામાં આવે છે, તો તે org/repo સ્તરે નબળાઈઓ શોધવા માટે GitHub સાથે કનેક્ટ થશે.
ઝીગેની ઇન્વેન્ટરી
જ્યારે આપણે આ રેપો પર Xygeni Scanner ચલાવીએ છીએ, ત્યારે તે ઉપયોગી સંપત્તિઓનો સમૂહ શોધે છે ( ઝીગેની ઇન્વેન્ટરી). ઇન્વેન્ટરી ઘણા વિવિધ પ્રકારના ભરેલી હશે CI/CD અસ્કયામતો, જેમ કે:
- આ SCM સિસ્ટમ જ્યાં રેપો સંગ્રહિત થાય છે
- આ SCM પ્લગઇન્સ સ્થાપિત/વપરાયેલ
- આ કોડ રિપોઝીટરી પોતે
- આ SCM સંસ્થા જ્યાં રેપોનો સંબંધ છે
- આ CI/CD Pipelineનોકરીઓ અને નોકરીઓ
- આ CI/CD સિસ્ટમ ચલાવી રહ્યા છીએ pipelines
- IaC સંપત્તિ રેપોમાં વ્યાખ્યાયિત
- બાહ્ય અવલંબન
- વગેરે.
અમારા ઉદાહરણમાં, આપણે અમુક ચોક્કસ સંપત્તિ પ્રકાર દ્વારા ઇન્વેન્ટરી ફિલ્ટર કરી શકીએ છીએ (SCM- અને CICD-સંબંધિત સંપત્તિઓ), તેથી આપણે જોઈ શકીએ છીએ કે:
- SCM સિસ્ટમ GitHub Cloud છે
- રેપો ગિટહબ ક્લાઉડમાં સંગ્રહિત છે અને તે ચોક્કસ ગિટહબ સંગઠનનો છે.
- બે છે pipelineGitHub દ્વારા સંચાલિત (CI/CD સિસ્ટમ)
- દરેક pipeline એક ચોક્કસ પગલું સમાવે છે
ઉપરોક્ત પસંદ કરીને pipeline આપણે કેટલીક નબળાઈઓ જોઈ શકીએ છીએ:
- At pipeline સ્તર, તે બંને માટે સંવેદનશીલ છે ડાયરેક્ટ અને પરોક્ષ PPE.
આપણે ઝેર પામેલા લોકોની વિગતો જોઈ શકીએ છીએ Pipeline અમલીકરણ નબળાઈઓ
ઝાયજેની શોધે છે કે તે D-PPE માટે સંવેદનશીલ કારણ કે તે એક પર ટ્રિગર થાય છે Pull Request ઇવેન્ટ અને ત્યાં કોઈ વધારાના સુરક્ષા નિયંત્રણો નથી, તેથી કોઈપણ રેપો વપરાશકર્તા તેમાં ફેરફાર કરી શકે છે pipeline અને તે ફેરફારો કોઈપણ સમીક્ષા અથવા મંજૂરી વિના અમલમાં મૂકવામાં આવશે.
એ જ અર્થમાં, ઝાયજેની પણ શોધે છે કે તે I-PPE માટે સંવેદનશીલ શેલ સ્ક્રિપ્ટ પર કોલ થવાને કારણે pipeline: કોઈપણ રેપો વપરાશકર્તા શેલ સ્ક્રિપ્ટમાં ફેરફાર કરી શકે છે અને તે ફેરફારો કોઈપણ સમીક્ષા અથવા મંજૂરી વિના અમલમાં મૂકવામાં આવશે.
શું તમે વધુ જાણવા માંગો છો?
PPEનો ઉપયોગ
PPE નો ઉપયોગ કરવા માટે, ચાલો એક એવી પરિસ્થિતિનો વિચાર કરીએ જ્યાં બે પ્રકારના રેપો વપરાશકર્તાઓ:
- An આંતરિક વપરાશકર્તા (તે રેપો પર કામ કરતો આંતરિક વિકાસકર્તા), રેપો પર લખવાની પરવાનગી સાથે
- An બાહ્ય વપરાશકર્તા (તે રેપો પર કામ કરતો આઉટસોર્સ્ડ ડેવલપર પરંતુ રેપો પર વાંચવાની પરવાનગી સાથે), એટલે કે રેપોને શાખા કરવાની મંજૂરી નથી અને ફોર્ક પર કામ કરવાની ફરજ પાડવામાં આવી.
ચાલો કલ્પના કરીએ કે બંને દૂષિત હુમલાખોરો છે (અથવા કોઈ દૂષિત અભિનેતા દ્વારા ઢોંગ કરવામાં આવ્યા છે). રિપોર્ટમાં કંઈક રહસ્ય છે અને બંને ઇચ્છે છે રેપો સિક્રેટ ચોરી કરવા માટે અને તેને હેકર-નિયંત્રિત સર્વર પર મોકલો. તે કરવા માટે, તેઓ પોઇઝન્ડનો લાભ લેશે Pipeline અમલીકરણ નબળાઈઓ pipeline.
બંને કિસ્સાઓમાં (બાહ્ય અને આંતરિક વપરાશકર્તા), તેઓ a ખોલે છે Pull Request સમાન ફેરફારો સાથે:
- આ pipeline અને શેલ સ્ક્રિપ્ટમાં ફેરફાર કરવામાં આવે છે થી રહસ્ય વાંચો પર્યાવરણમાંથી અને તેને હેકર-નિયંત્રિત સર્વર પર મોકલો
ફેરફારો નીચે મુજબ હોઈ શકે છે:
બંને વપરાશકર્તાઓ એક બનાવશે Pull Request સુધારાઓ સાથે. પીઆરની રચના પર, GitHub બંને ફેરફારોનો અમલ કરશે (પહેલાની સમીક્ષા કે મંજૂરીની જરૂર વગર), જેના પરિણામે નીચેના પરિણામો આવે છે:
લખવા અને વાંચવાના વપરાશકર્તાઓ માટે પણ એ જ, બંને કિસ્સાઓમાં D-PPE અને I-PPE ચલાવવામાં આવે છે, એ તફાવત સાથે કે વાંચનાર વપરાશકર્તા રહસ્યો ઍક્સેસ કરી શકતો નથી. (!!!!)
આનું કારણ એ છે કે, ફોર્કમાંથી આવતા PRના કિસ્સામાં, GitHub રેપો સિક્રેટ્સની ઍક્સેસની મંજૂરી આપતું નથી. વાંચનાર વપરાશકર્તા રહસ્યો વાંચી શકતો નથી, તેમ છતાં તે/તેણી કોઈપણ અન્ય પ્રોગ્રામ ચલાવી શકે છે. એક લાક્ષણિક હુમલાનું ઉદાહરણ એવા PR બનાવવાનું છે જે ક્રિપ્ટો માઇનર ડાઉનલોડ કરે છે, તેથી GitHub રનર ઝેરી pipeline.
અલબત્ત, આ સલામત વાતાવરણ નથી!! રેપો એડમિન તેનાથી બચવા માટે શું કરી શકે છે?
થોડી ગૂગલિંગ પછી, રેપો એડમિન આમાં ફેરફાર કરવાનું નક્કી કરે છે pipeline પર ટ્રિગર થવા માટે પુલ_રિક્વેસ્ટ_ટાર્ગેટ ઘટના. શા માટે? કારણ કે pipelinepull_request_target પર ટ્રિગર થયેલ s એક્ઝિક્યુટિંગને મંજૂરી આપતા નથી pipeline ફેરફારો, એટલે કે કોઈપણ વપરાશકર્તા ફેરફાર છતાં "મૂળ" pipeline ચલાવવામાં આવશે.
અમારા ઉદાહરણને અનુસરીને, હુમલો પહેલા જેવો જ થશે. આ પછી શું થશે? pipeline ફેરફાર?
ઈચ્છિત તરીકે, D-PPE અમલમાં મૂકાયેલ નથી પરંતુ, કારણ કે I-PPE હજુ પણ છે, રીડ યુઝર હવે રેપો સિક્રેટને એક્સેસ કરી શકશે!!!
વાંચેલા વપરાશકર્તા પાસે હવે રહસ્યોની ઍક્સેસ છે તેનું કારણ શું છે? જોકે pipeline સુધારી શકાતી નથી, શેલ સ્ક્રિપ્ટમાં ફેરફાર કરવાનું હજુ પણ શક્ય છે. જ્યારે એક pipeline pull_request_target પર ટ્રિગર થાય છે, તે વિશેષાધિકૃત મોડમાં એક્ઝિક્યુટ થશે so તે શેલ સ્ક્રિપ્ટ પણ હશે., જેના પરિણામે શેલ સ્ક્રિપ્ટને રેપો સિક્રેટ્સની ઍક્સેસ મળે છે!!
નિવારક પગલાંઓ
GitHub દૂષિત PR સામે રક્ષણ આપવા માટે કેટલાક પગલાં પૂરા પાડે છે.
શાખા સુરક્ષા નિયમો
GitHub વડે તમે પસંદ કરેલી શાખાઓ પર શાખા સુરક્ષા નિયમો વ્યાખ્યાયિત કરી શકો છો.
તમારી સુરક્ષિત શાખાઓ માટે, તમે એક નીતિનો ઉલ્લેખ કરી શકો છો જે જરૂર છે pull request મર્જ કરતા પહેલા (તેમજ વધારાની શરતો જેમ કે જરૂરી સંખ્યામાં મંજૂરીઓ, કોડ માલિકો તરફથી સમીક્ષાઓ, વગેરે.)
ખાસ વિચારણાને પાત્ર બે શરતો છે:
- "ઉલ્લેખિત કલાકારોને જરૂરી બાયપાસ કરવાની મંજૂરી આપો pull requests".
- "ઉપરોક્ત સેટિંગ્સને બાયપાસ કરવાની મંજૂરી આપશો નહીં"
મોટાભાગની શરતો નીતિમાં કડકતા ઉમેરે છે, પરંતુ આ શરતો નીતિને હળવી બનાવે છે અને તેનાથી દૂષિત પ્રવૃત્તિઓ માટે દ્વાર ખુલ્લું પડી શકે છે, ઉદાહરણ તરીકે, જ્યારે "વિશેષાધિકૃત" વ્યક્તિઓ દ્વારા ઓળખપત્રોની ચોરી કરવામાં આવે છે.
GITHUB_TOKEN પરવાનગીઓ પ્રતિબંધિત કરો (ઓછામાં ઓછા વિશેષાધિકાર)
GitHub ટોકન પરવાનગીઓ ફક્ત જરૂરી પરવાનગીઓ સુધી મર્યાદિત કરો; આ રીતે, જો હુમલાખોરો તમારી સાથે ચેડા કરવામાં સફળ થાય તો પણ pipeline, તેઓ બહુ કંઈ કરી શકશે નહીં.
ઉપયોગ કરીને સ્ટ્રિંગ ઇન્ટરપોલેશન ટાળો pipeline env ચલ
જ્યારે પણ તમે તમારામાં કેટલાક ઇનપુટ ચલોનો ઉપયોગ કરો છો pipeline, ધ્યાન રાખો કે તેમને ડિફોલ્ટ રૂપે "અવિશ્વસનીય" ડેટા તરીકે ગણવામાં આવવું જોઈએ (તેમની સામગ્રી અંતિમ વપરાશકર્તા દ્વારા નિયંત્રિત થાય છે). જુઓ અવિશ્વસનીય ક્રિયાઓ અને કાર્યપ્રવાહ સુરક્ષિત અને ગીથબ ક્રિયાઓ શીખો.
સ્ક્રિપ્ટમાં ઇનપુટ વેરીએબલ દાખલ કરવા માટે તમારે હંમેશા સ્ટ્રિંગ ઇન્ટરપોલેશનનો ઉપયોગ કરવાને બદલે પર્યાવરણ વેરીએબલનો ઉપયોગ કરવો જોઈએ.
વર્કફ્લો રન અને મંજૂરીની આવશ્યકતાઓ
માટે જાહેર રિપોઝ, ગિટહબ સ્પષ્ટ કરવાની મંજૂરી આપે છે "બાહ્ય" પીઆર સાથે કેવી રીતે કામ કરવું.
GitHub સંગઠન સેટિંગ્સ ("Org >> સેટિંગ્સ >> ક્રિયાઓ >> સામાન્ય") બાહ્ય PR નું સંચાલન કેવી રીતે કરવું તે સ્પષ્ટ કરે છે:
ડિફૉલ્ટ રૂપે, GitHub ને પહેલી વખત યોગદાન આપનારાઓ માટે PR મંજૂરીની જરૂર પડશે, જે દૂષિત વિનંતી હુમલાઓને વધુ જટિલ બનાવે છે. તેમ છતાં, હુમલાખોર પ્રોજેક્ટ જાળવણીકારોનો વિશ્વાસ મેળવી શકે છે, ઉદાહરણ તરીકે, કેટલાક નિર્દોષ યોગદાન આપીને pull request વાસ્તવિક હુમલા પહેલા.
આ અર્થમાં, આ ત્રીજો વિકલ્પ (બધા બહારના સહયોગીઓ માટે મંજૂરી જરૂરી) ઉચ્ચ સ્તરનું નિયંત્રણ ઉમેરે છે.
માટે ખાનગી રિપો, ગિટહબ સંસ્થા- અને રેપો-સ્તર બંને પર મદદરૂપ નિયંત્રણ પણ પૂરું પાડે છે.
"આમાંથી વર્કફ્લો ચલાવો Pull Requests” (ડિફોલ્ટ રૂપે ચેક કરેલ નથી) વપરાશકર્તાઓને ફોર્ક પીઆરમાંથી વર્કફ્લો ચલાવવાની મંજૂરી આપે છે (GITHUB_TOKEN નો ઉપયોગ કરીને ફક્ત વાંચવા માટેની પરવાનગીઓ સાથે અને રહસ્યોની ઍક્સેસ વિના). છેલ્લા વિકલ્પ સાથે આ વિકલ્પ પસંદ કરીને (“ફોર્ક પીઆર વર્કફ્લો માટે મંજૂરીની જરૂર છે”), તમે ખાનગી રિપોઝીટરી જેવી જ નીતિ (ઉપર બતાવ્યા પ્રમાણે) સુધી પહોંચી શકો છો.
જેમ આપણે વાંચેલા વપરાશકર્તાના PPE શોષણમાં જોયું છે, ફોર્કમાંથી વર્કફ્લો ચલાવવાની મંજૂરી આપી રહ્યા છીએ pull requests અસુરક્ષિત છે!!
બાકીના વિકલ્પો ("ફોર્કથી વર્કફ્લોમાં લખવાના ટોકન્સ મોકલો pull requests"અને"for માંથી વર્કફ્લોમાં રહસ્યો અને ચલો મોકલો pull requests") સુરક્ષા સ્તર ઘટાડો ફોર્ક પીઆર પર લાગુ.
તમે આ ફોર્ક પોલિસીને ઓર્ગેનાઇઝેશન લેવલ પર અથવા રેપો-લેવલ પર વ્યાખ્યાયિત કરી શકો છો. જો પોલિસી ઓર્ગેનાઇઝેશન લેવલ પર અક્ષમ હોય, તો તેને રેપો લેવલ પર સક્ષમ કરી શકાતી નથી. પરંતુ, જો પોલિસી ઓર્ગેનાઇઝેશન લેવલ પર સક્ષમ હોય, તો તેને રેપો-લેવલ પર અક્ષમ કરી શકાય છે.
રીકેપ
અમને આશા છે કે તમે કેટલાક હોવાના પરિણામો જોયા હશે pipeline ઝેર માટે સંવેદનશીલ Pipeline અમલ. તે ખૂબ સરળ છે commit સંવેદનશીલ pipeline, અને સુરક્ષિત લખવું મુશ્કેલ છે.
તેથી આવી નબળાઈઓથી વાકેફ રહેવા માટે Xygeni સ્કેનરનો ઉપયોગ કરવો ખૂબ જ મૂલ્યવાન છે.
જ્યાં સુધી તમને તેના અસ્તિત્વની જાણ ન હોય ત્યાં સુધી તમે કોઈ સમસ્યાનો ઉકેલ લાવી શકતા નથી !!
પણ... હજુ પણ એક પ્રશ્ન બાકી છે... I-PPE થી કેવી રીતે બચવું?
આ અમારી આગામી પોસ્ટનો વિષય હશે 🙂 … પરોક્ષ ઝેર Pipeline અમલ (I-PPE) !!
