რა არის დოსფუსკაცია? რატომ უნდა მიაქციონ ყურადღება დეველოპერებმა
აი, საფრთხის მოკლე მიმოხილვა: წარმოიდგინეთ, რომ განიხილავთ PR-ს, რომელიც მცირე უტილიტის განახლებას ჰგავს. შიგნით დამალული კონტრიბუტორი დაამატებს რაღაც უვნებელ დამხმარე სკრიპტს. თუმცა, შერწყმისას ის CI-ს დროს მუშაობს. pipeline და იწვევს ციკლს, რომელიც ჩუმად მოიხმარს მთელ მეხსიერებას, რაც აზიანებს აწყობის პროცესს.
დოსფუსკაცია არის შიდა მომსახურების უარყოფის (DoS) შეტევის სახეობა, რომელიც შენიღბულია კოდის დაბინდვის ტექნიკით. ის აერთიანებს შესრულების შეფერხებისთვის შექმნილ ლოგიკას, როგორიცაა უსასრულო ციკლები ან მეხსიერების გადატვირთვა, ტაქტიკასთან, რომელიც მალავს მის რეალურ ქცევას, რაც ართულებს მის აღმოჩენას მიმოხილვების ან აუდიტის დროს. ეს გარე დარტყმა არ არის; ის უკვე თქვენს კოდშია და ელოდება თქვენი აწყობის ან წარმოების პროცესის აფეთქებას.
რატომ გაინტერესებთ? ტრადიციული ტიპის მომსახურების უარყოფის შეტევებისგან განსხვავებით, რომლებიც თქვენს სერვერებს ტრაფიკით ავსებენ, დოსფუსკაცია თვალსაჩინო ადგილას იმალება და ხშირად კოდის მიმოხილვას ან პაკეტის აუდიტს გადის. ეს თქვენს სისტემაში ჩადებული ლოგიკური ბომბია. pipeline.
რეალური მაგალითი: An npm პაკეტი შეიცავს შენიღბულ უსასრულო ციკლს. ის ინსტალაციას წარმატებით გადის, მაგრამ ოპერაციულ რეჟიმში მეხსიერებას აჭიანურებს მანამ, სანამ თქვენი აპლიკაცია არ გაითიშება. ეს აჩვენებს, თუ როგორ იქცევა ობსუქციის ტექნიკით მხარდაჭერილი დოსფუსკაცია მომსახურების უარყოფის ყველაზე მავნე ტიპის შეტევების ფარულ ვარიანტად.
ტიპური DoS vs. Dosfuscation: რეალური განსხვავებები რისკში
დოსფუსკაცია მომსახურების უარყოფის შეტევების ქვეტიპია. ის განსხვავდება მომსახურების უარყოფის შეტევების ტრადიციული ტიპებისგან იმით, რომ შიდა რეჟიმში ხორციელდება დაბინდული კოდის მეშვეობით და არა ქსელური ტრაფიკის მეშვეობით.
წარმოიდგინეთ ეს: თქვენ ამტკიცებთ PR-ს GitHub-ში. ტესტები წარმატებით სრულდება, იწყება აწყობა და შემდეგ თქვენი შემსრულებელი იჭედება. თქვენ ასწორებთ წარუმატებელ GitHub Actions დავალების გამართვას, რომლის დროც განუწყვეტლივ იწურება. აღმოჩნდა, რომ მცირე დამოკიდებულებაში დოსფუსკირებულმა დატვირთვამ ინსტალაციის შემდგომ სკრიპტში უსასრულო ციკლი შემოიტანა.
როდესაც დეველოპერები მომსახურების უარყოფაზე ფიქრობენ, ისინი, როგორც წესი, წარმოიდგენენ გარედან შიგნით სცენარს, მაგალითად, მავნე მოთხოვნების გროვას, რომელიც აზიანებს API-ს ან ბოტნეტებს და ამოწურავს გამტარუნარიანობას. ეს არის მომსახურების უარყოფის შეტევების კლასიკური ტიპები და ჩვენი უმეტესობა მზად არის მათთვის. ჩვენ გვაქვს WAF-ები, ვიყენებთ სიჩქარის შეზღუდვას და ვქმნით მასშტაბირებად ინფრასტრუქტურას, რომელსაც შეუძლია დარტყმის ატანა.
თუმცა, დოსფუსკაცია გარედან არ მოდის. ის პირდაპირ თქვენს კოდის ბაზაშია დაკავშირებული. ის იმალება დამოკიდებულებებში, ფარულად აღწევს CI-ში. pipelines და ელოდება შესრულებას, რომ ყველაფერი ააფეთქოს. არანაირი firewall-ის რეგულირება ან DDoS შემარბილებელი შეაჩერებს მას, რადგან ის არასდროს მოგზაურობს ქსელში; ის უკვე სახლშია.
ეს დოსფუსკაციას მომსახურების უარყოფის განსაკუთრებით ფარულ ფორმად აქცევს. ის არ აცხადებს საკუთარ თავს ქსელის ხმაურით. ის კლავს შიგნიდან, შექმნის დროს, გაშვების დროს ან როდესაც კონკრეტული ლოგიკური განშტოება დაზარალდება. და რადგან ის დამალულია კოდში მოწინავე დაბნევის ტექნიკის გამოყენებით, თქვენ ვერ დაინახავთ მას, თუ ღრმად არ შეისწავლით.
ამიტომაც DevSecOps გუნდები საჭიროა პერიმეტრის დაცვის მიღმა ფიქრი. აპლიკაციის დონის უსაფრთხოებაც არანაკლებ მნიშვნელოვანია. თუ თქვენი ერთადერთი ყურადღება ცუდი ტრაფიკის თავიდან აცილებაზეა ორიენტირებული, თქვენ გამოტოვებთ თქვენს საცავში უკვე არსებულ დატვირთვას.
როგორ იყენებენ თავდამსხმელები დაბნეულობას DoS ლოგიკის დასამალად კოდში
შესაძლოა, ეს მოქმედებაში მაშინ ნახოთ, როდესაც სამუშაო პროცესი მოსალოდნელზე გაცილებით მეტხანს გრძელდება, ან უარესი, საერთოდ არ მთავრდება. ერთ-ერთი მაგალითია გუნდი, რომელიც ტესტებს ატარებდა Docker-ის კონტეინერში. GitHub მოქმედებებიმესამე მხარის მოდულის მეშვეობით დაემატა JavaScript-ის ტესტის მცირე დამხმარე. ის დაბნეული იყო უსასრულო მეხსიერების განაწილების ციკლის შესანიღბად, რაც კვანძის პროცესს რეაგირების შეწყვეტას იწვევდა.
დაბნეული DoS დატვირთვები ხშირად შეუმჩნევლად იშლება CI სამუშაო პროცესებში. მაგალითად, GitHub Actions pipeline შესაძლოა, ერთი შეხედვით უვნებელი სკრიპტი გაუშვას, რომელიც ჩაშენებული უსასრულო ციკლის გამო მოულოდნელად შეაჩერებს დავალებას.
ამის რეალობად ქცევისთვის, აი, როგორ შეიძლება გამოიყურებოდეს დოსფუსკირებული დატვირთვა ყოველდღიურ კოდში.
JavaScript-ის მაგალითი: დამალული უსასრულო ციკლი
ეს შენიღბული ლოგიკის გამოყენებით განუსაზღვრელი ვადით ავსებს მეხსიერებას, რაც საბოლოოდ აპლიკაციის მუშაობას აფერხებს.
Python-ის მაგალითი: დაბნელებული CPU Hog
import base64
exec(base64.b64decode("d2hpbGUgVHJ1ZToKICBhcCA9IFtdCiAgZm9yIGkgaW4gcmFuZ2UoMTAwMDAwMDApOgogICAgYXAucHVzaChzdHIoaSkp"))
ეს base64-ით კოდირებული ციკლი დაუსრულებლად მუშაობს, ერთი შეხედვით საეჭვოდ არ ჩანს და მეხსიერებას ძალიან იტვირთავს.
სად იმალება სასარგებლო ტვირთი: რეალური სამყაროს დოსფუსკაციის სცენარი
დოსფუსკირებული დატვირთვები ხშირად იმალება თვალსაჩინო ადგილას, მესამე მხარის პაკეტებში, ღია კოდის პაკეტებში. pull requests, ან შიდა სკრიპტები, რომლებიც ხელახლა გამოიყენება შემოწმების გარეშე. თავდამსხმელები ეყრდნობიან განვითარების სიჩქარეს და ავტომატიზაციას, რათა შეუმჩნევლად გაიპარონ, თქვენს ღრმად ჩანერგავენ ლოგიკურ ბომბებს. pipeline.
რეალური სცენარი გვეხმარება იმის ილუსტრაციაში, თუ როგორ ხდება ეს:
თქვენ იყენებთ GitHub Actions-ს თქვენი CI სამუშაო პროცესის გასაშვებად. თქვენი .github/workflows/build.yml პროექტის დამოკიდებულებების ინსტალაცია. ერთ-ერთი მათგანია გარდამავალი npm პაკეტი, რომელიც დაინსტალირებულია არა უშუალოდ თქვენ მიერ, არამედ დამოკიდებულების დამოკიდებულებად. ის აცხადებს, რომ ეხმარება რაღაც ტრივიალურში, როგორიცაა სტრიქონების მანიპულირება.
მაგრამ პაკეტის შიგნით, რომელიც დამალულია დაბინდვის ტექნიკის გამოყენებით, ლოგიკური ბომბია. შესაძლოა, ეს იყოს უსასრულო მეხსიერების განაწილების ციკლი, რომელიც გააქტიურებულია პოსტინსტალაცია სკრიპტი ან თქვენს ტესტებში გაშვების დროს იმპორტი. ის შესრულებამდე უმოქმედო რჩება, გაფრთხილებები და აუდიტის დროშები არ არის.
უეცრად, თქვენი CI გამშვები სისტემა იჭედება. პროცესორისა და მეხსიერების დატვირთვა იზრდება. დავალების შესრულების დრო იწურება. თქვენი აწყობა ან განლაგება ვერ ხერხდება.
ეს მხოლოდ ჰიპოთეტური არ არის. მსგავსი ინციდენტები არაერთხელ დაფიქსირებულა. ისინი აჩვენებს, თუ როგორ ზრდის დოსფუსკაცია თქვენი ინსტრუმენტების ჯაჭვის მიმართ ნდობას, იყენებს ავტომატიზირებულ სამუშაო პროცესებს, სწრაფ შერწყმას და არაპირდაპირ დამოკიდებულებებს.
სად იმალება ეს ტვირთები, როგორც წესი?
- მესამე მხარის პაკეტები: განსაკუთრებით npm-დან, PyPI-დან ან Maven-დან.
- ღია კოდის PR-ები: სასარგებლო განახლებებად შენიღბული ფარული ლოგიკით.
- შიდა სკრიპტები: ხელახლა გამოყენებული სნიპეტები სათანადო დადასტურების ან განხილვის გარეშე.
თავდამსხმელები იყენებენ დაბინდვას აღმოჩენის გადასადებად, დანარჩენს კი ზედაპირული კოდის მიმოხილვებსა და ავტომატიზირებულ დამოკიდებულებების განახლებებს ეყრდნობიან.
როგორ ამოვიცნოთ დოსფუსკაცია თქვენს კოდსა და დამოკიდებულებებში
გამოიყენეთ სტატიკური ანალიზი უცნაური ლოგიკის მოსაძებნად
გამოიყენეთ ინსტრუმენტები, რომლებიც:
- აღმოაჩინეთ დაბნელების ტექნიკები, როგორიცაა დაშიფრული კონტროლის ნაკადი ან სტრიქონების რეკონსტრუქცია.
- დროშის ლოგიკა, რომელიც ძალიან რთულია მარტივი მოდულებისთვის.
- მონიშნეთ ფუნქციის ან სკრიპტის ნიმუშები, რომლებიც მსგავსია მომსახურების უარყოფის შეტევების ტიპებისა.
დამოკიდებულებების სკანირება არა მხოლოდ ვერსიის შემოწმებით
ვერსიის ნომრების შემოწმებით ნუ შეჩერდებით:
- შეხედეთ რეალურ კოდს შიგნით.
- პრიორიტეტი მიანიჭეთ პაკეტის ბოლო განახლებების გადახედვას.
- მოძებნეთ კოდირებული სტრიქონები, ფარული ლოგიკა ან დოსფუსკაციის მარკერები.
საეჭვოს ხელით განხილვა Pull Requests
უყურეთ:
- ზედმეტად რთული ცვლილებები მარტივ განახლებებში.
- ახალ კოდში ბუნდოვანი ან წაუკითხავი ლოგიკაა.
- PR-ები, რომლებიც ცნობილ დაბნელების ტექნიკას ნერგავენ.
დოსფუსკაცია მაშინ იწყება, როდესაც ყველა ვარაუდობს, რომ „ეს მხოლოდ მცირე ცვლილებაა“.
როგორ ავიცილოთ თავიდან დოსფუსკაციის შედეგად გამოწვეული დაზიანება CI/CD
CI გარემოში, როგორიცაა GitHub Actions, GitLab CI ან CircleCI, პრევენცია გულისხმობს კონტროლის დაყენებას, რომელიც ადრეულ ეტაპზე აღმოაჩენს და ბლოკავს დაბინდულ დატვირთვას. მაგალითად, PR მიმოხილვების აღსრულება ყველა სამუშაო პროცესისთვის, რომელიც შეიცავს shell სკრიპტებს ან ინსტალაციას. hooksდა მონიტორინგი .yml pipeline კონფიგურაციები დაუდასტურებელი მესამე მხარის ქმედებებისთვის.
CI/CD ეს არის დოსფუსკაციის სათამაშო მოედანი. აი, როგორ უნდა ჩაკეტოთ ის:
- დაამატეთ სტატიკური სკანერები ყველა PR-სა და აწყობას.
- გამოიყენეთ მხოლოდ სანდო, დამოწმებული წყაროებიდან მიღებული პაკეტები.
- აკონტროლეთ აწყობის რესურსების გამოყენება; პიკები შეიძლება ფარულ ლოგიკას ნიშნავდეს.
- შეადარეთ ყველა დამოკიდებულება შემოწმებულს SBOM.
- აკრძალეთ დაბნელების გავრცელებული ტექნიკის გამოყენება დოკუმენტური დასაბუთების გარეშე.
აღარ იქნება „დააინსტალირეთ და იმედი გქონდეთ“. პრევენცია ნიშნავს ქონას guardrails ჩაშენებულია თქვენს სამუშაო პროცესში. დოსფუსკაციის ადრეული გამოვლენა ხელს უშლის მომსახურების უარყოფის შეტევების ყველაზე დამანგრეველ ტიპებს.
ქსიგენის როლი: დოსფუსკაციის დაჭერა წარმოებამდე
ქსიგენი ეხმარება DevSecOps გუნდებს შეაჩერონ დოფსფუსკაცია, სანამ ის შეფერხებას გამოიწვევს, უსაფრთხოების ინტელექტის ინტეგრირებით მთელ თქვენს სისტემაში. განვითარების სამუშაო პროცესიის სპეციალიზირებულია დაბნევის ტექნიკის აღმოჩენასა და პოლიტიკაზე დაფუძნებული აღსრულებაზე. guardrails რომლებიც ხელს უშლიან ფარულ მომსახურების უარყოფის შეტევებს წარმოებამდე მიღწევაში.
PR მიმოხილვებში
Xygeni სკანირებს კოდის დიფერენციებს, რათა აღმოაჩინოს დაბნეულობის ისეთი ნიშნები, როგორიცაა:
- გამოყენების ევალება ან მსგავსი დინამიური შესრულების მეთოდები.
- Base64 ან თექვსმეტობით კოდირებული სტრიქონები, რომლებიც განკუთვნილია ლოგიკის დასამალად.
- საეჭვო მართვის ნაკადი, როგორიცაა არაბუნებრივი ციკლები ან ლოგიკური განშტოების ჩახლართვა.
ეს შაბლონები იწვევს რეალურ დროში შეტყობინებებს pull request მიმოხილვები, იქნება ეს პირველი თუ მესამე მხარის კოდი, რაც უსაფრთხოების მიმომხილველებს დოსფუსკაციის ადრეულ ეტაპზე აღმოჩენაში ეხმარება.
დამოკიდებულების ანალიზის დროს
Xygeni აანალიზებს არა მხოლოდ პაკეტის მეტამონაცემებს, არამედ ახალი ან განახლებული დამოკიდებულებების რეალურ წყაროსაც. ის აღმოაჩენს დამხმარე ფუნქციებში ან ინსტალაციის შემდგომ სკრიპტებში ჩადგმულ დაბინდულ ლოგიკას, რითაც აღნიშნავს მაღალი რისკის მქონე პაკეტებს, მაშინაც კი, თუ ისინი ერთი შეხედვით ლეგიტიმურად გამოიყურებიან.
აშენების დროს CI/CD Pipelines
Xygeni აკვირდება CI დავალებებს ქცევის ანომალიების აღმოსაჩენად. თუ ბილდი მოულოდნელად მოიხმარს უჩვეულო CPU-ს ან მეხსიერებას, Xygeni აკონტროლებს პიკს კონკრეტულ კოდთან ან ცოტა ხნის წინ დანერგილ პაკეტებთან. ის ავტომატურად აკავშირებს გაშვების დროს ქცევას სტატიკურ მონაცემებთან, რათა აღმოაჩინოს დამალული DoS დატვირთვები, სანამ ისინი შეაფერხებენ მიწოდებას.
როგორც პოლიტიკის აღსრულების ფენა
შეგიძლიათ Xygeni-ს კონფიგურაცია გაუკეთოთ ისეთი სარისკო ნიმუშების პირდაპირ დაბლოკვას, როგორიცაა:
- დამოკიდებულებების აკრძალვა, რომლებიც მოიცავს base64-ით დაშიფრულ კოდს ან ევალება
- ინსტალაციის შემდგომი ყველა სკრიპტისთვის ხელით დამტკიცების მოთხოვნა
- ნულოვანი ტოლერანტობის წესების აღსრულება PR-ებში ან CI დავალებებში დაბნეული კონტროლის ნაკადისთვის
Xygeni-ს დახმარებით, უსაფრთხოება პროაქტიული ხდება. ის გუნდებს ხილვადობას, ადრეულ გაფრთხილებებს და პოლიტიკის დონეზე აღსრულებას აძლევს იმ ტიპის დაბნევის ტექნიკის წინააღმდეგ, რომლებზეც დოსფუსკაციაა დამოკიდებული. Xygeni-ის ყველა ეტაპზე, PR-ებში, დამოკიდებულების სკანირებასა და CI გაშვების დროს ჩასმით, თქვენ საფრთხეს მანამ აფიქსირებთ, სანამ ის პოსტ-მოკვლევად იქცევა.
ასე რომ, დოსფუსკაცია თქვენს კოდს თქვენს წინააღმდეგ აბრუნებს
დოსფუსკაცია მხოლოდ თეორიული რისკი არ არის; ეს არის რეალური და მზარდი შეტევის ვექტორი, რომელიც თქვენი განვითარების პროცესს იარაღად აქცევს. ის წარმატებით ვითარდება სწრაფ გამოშვებებს, ავტომატურ ინსტალაციებსა და დამოკიდებულების ჯაჭვებს შორის არსებულ ხარვეზებში, რომელთა ხელით აუდიტისთვის ძალიან რთულია. ეს მხოლოდ უსაფრთხოების საკითხი არ არის; ეს პროგრამული უზრუნველყოფის ინჟინერიის გამოწვევაა. დაბნეული მომსახურების უარყოფის შემცველი დატვირთვები ტრადიციულ დაცვას გვერდს უვლიან კოდში უშუალოდ ჩაშენებით, სადაც firewall-ები და ტრაფიკის ფილტრები ვერ აღწევენ.
დეველოპერებისთვის, დასკვნა მარტივია: თუ კოდს წერ, დაამტკიცე pull requests, ან მართვა CI/CD pipelineს, თქვენ წინა ხაზზე ხართ. უსაფრთხო აწყობა მხოლოდ სუფთა კოდს არ ეხება; ისინი საჭიროებენ ხილვადობას, კონტროლს და პოლიტიკაზე დაფუძნებულ დაცვას ყოველ ეტაპზე. pipeline.
გასცდით საკონტროლო სიებს. ინტეგრირეთ დაბნეულობის აღმოჩენა თქვენს სამუშაო პროცესში. დააკვირდით base64 სტრიქონებს, უცნაურ ლოგიკას ან CI რესურსების გამოყენების მოულოდნელ მკვეთრ მატებებს. დაადასტურეთ არა მხოლოდ რა დააინსტალირებ, მაგრამ რას აკეთებს. მკურნალობა pipeline კონფიგურაციები, როგორიცაა წარმოების კოდი. ავტომატიზაცია guardrails. მონიშნეთ ის, რაც უცნაურად გამოიყურება, მაშინაც კი, თუ ის „მუშაობს“.
რადგან დოსფუსკაცია არ ყვირის. ის ელოდება. და თუ მას არ ეძებ, ის გაგიპარავს.
