ყველაფერი რაც უნდა ვიცოდეთ ახალი OpenSSL დაუცველობის შესახებ

CVE-2022-3602 & CVE-2022-3786

სისტემების დაცვამდე უნდა გავიგოთ, რის დაცვას ვცდილობთ და როგორ გავაკეთოთ ეს. დღეს ჩვენ ვიკვლევთ ორ დაუცველობას, რომლებმაც საზოგადოების ყურადღება გასულ თვეში მიიპყრო. რაც მთავარია, თქვენ შეიტყობთ თუ, როგორ გამოასწოროთ ისინი და რა გავლენის მოხდენა შეუძლიათ მათ.

2022 წლის 1 ნოემბერს, OpenSSL-ის გუნდმა გამოაქვეყნა ბიულეტენი, რომელშიც დეტალურად იყო აღწერილი ორი მაღალი სიმძიმის დაუცველობა, CVE-2022-3602 და CVE-2022-3786.

CVE-2022-3602 წინასწარ იყო გამოცხადებული, როგორც კრიტიკული ბაგი, მაგრამ მოგვიანებით ის შეფასდა, როგორც მაღალი, რამაც საზოგადოების უკმაყოფილება გამოიწვია. 17 ოქტომბერს CVE-2022-3602 -ის შესახებ განცხადება გაკეთდა “პოლარული დათვის” მიერ, ხოლო მომდევნი დღეს ვიქტორ დუხოვნიმ განაცხადა CVE-2022-3786 -ს შესახებ.

ცნობილი Heartbleed დაუცველობის შემდეგ (CVE-2014-0160) ეს პირველი პრობლემაა, რომელმაც სიმძიმის ამ დონეს მიაღწია.

 

ამ პოსტში ჩვენ განვიხილავთ ორ ახალ OpenSSL დაუცველობას, მაგრამ ძირითადად ყურადღებას გავამახვილებთ CVE-2022-3602-ის ტექნიკურ დეტალებზე.

 

რა არის და როგორ გამოიყენება OpenSSL?

OpenSSL ბიბლიოთეკა გამოიყენება კრიპტოგრაფიული ფუნქციებისთვის, განსაკუთრებით ქსელური კავშირების კონტექსტში.

მაგალითად, ვებ სერვერები ხშირად იყენებენ OpenSSL-ს დაშიფრული კავშირების შესაქმნელად. OpenSSL ასევე იყენებენ ფოსტის სერვერები და VPN ტექნოლოგიები, როგორიცაა OpenVPN, უსაფრთხო საკომუნიკაციო არხების შესაქმნელად. ამ ბიბლიოთეკას მოიცავს პროდუქტების ფართო სპექტრი, მათ შორის ქსელური მოწყობილობები, ჩაშენებული სისტემები და კონტეინერის სურათები.

 

OpenSSL შედგება სამი ძირითადი კომპონენტისგან:

• libcrypto – კრიპტოგრაფიული ბიბლიოთეკა მრავალი პროტოკოლის რეალიზაციით
• libssl- ბიბლიოთეკა, რომელიც ახორციელებს ყველა TLS პროტოკოლს TLSv1.3-მდე
• OpenSSL- command line ბრძანების ხაზის პროგრამა სხვადასხვა ოპერაციებისთვის (მაგ. სერთიფიკატების გენერირება)

რა სახის დაუცველობასთან გვაქვს საქმე?

ეს დაუცველობა წარმოადგენს მეხსიერების დაზიანებას, რომელიც ასევე ცნობილია როგორც ბუფერის გადავსება/გადინება, რომლის დროსაც თავდამსხმელებს შეუძლიათ თვითნებური კოდის გაშვება მსხვერპლის მანქანაზე და მისი გამოყენება.

CVE-2022-3786

X.509 ელ.ფოსტის მისამართის ცვლადი სიგრძის ბუფერის გადავსება

დაუცველობა რჩება TLS სერთიფიკატის ანალიზის დადასტურების შემდეგ. ეს იწვევს სტეკზე ოთხი ბაიტის გადინებას. თავდამსხმელს შეუძლია შექმნას მავნე ელ.ფოსტის მისამართი სერტიფიკატში, რათა გადაავსოს რამდენიმე ბაიტი, რომელიც შეიცავს სიმბოლოს ‘.’ (ათწილადი 46) სტეკში.

CVE-2022-3602

X.509 ელფოსტის მისამართი 4-ბაიტიანი ბუფერული გადავსება

CVE-2022-3602 ჩნდება TLS სერტიფიკატის ანალიზის შემდეგ. განსხვავება ისაა, რომ დაუცველობა ჩნდება სახელის შეზღუდვის შემოწმების შემდეგ. მნიშვნელოვანია აღინიშნოს, რომ წარმატების მისაღწევად სანდო CA-მ ხელი უნდა მოაწეროს მავნე სერთიფიკატს.

სტატისტიკა, ან როგორ განვსაზღვროთ საფრთხის დონე

რამდენად დიდია პრობლემა?

ცხადია, ჩვენ არ გვაქვს Heartbleed-ის ახალი ვერსია. ქვემოთ მოყვანილი მაგალითები გვიჩვენებს, Heartbleed-თან შედარებით რამდენად ნაკლები ეგზემპლარები ხვდებიან გავლენის ქვეშ. ჩვენ შევაგროვეთ მონაცემები იმ ეგზემპლარებთან დაკავშირებით, რომლებიც იყენებენ OpenSSL-ის დაუცველ ვერსიებს Shodan-ისგან.

 

 

 

როგორც დიაგრამაზე ჩანს OpenSSL ვერსიით დაახლოებით 550,000 შემთხვევაა დაუცველი. აღსანიშნავია, რომ ყველა ეს შემთხვევა არ არის რეალურად დაუცველი, რადგან მნიშვნელოვან როლს თამაშობს სტეკის განლაგება და დაცვა.

მათი უმრავლესობა იყენებს OpenSSL 3.0.0-ს, სადაც პირველად დაინერგა punycode decode ფუნქცია.

უახლესი OpenSSL ვერსიები შედის მრავალი პოპულარული Linux დისტრიბუტორების ახალ გამოშვებებში, როგორიცაა Redhat Enterprise Linux 9, Ubuntu 22.04+, CentOS Stream9, Kali 2022.3, Debian 12 და Fedora 36.

Docker-ის შეფასებით დაახლოებით 1000 სურათის საცავი შეიძლება დაზარალდეს, როგორებიცაა Docker Official Images და Docker Verified Publisher.

Akamai-მ ჩაატარა კვლევა საკუთარ ინფრასტრუქტურაზე, სადაც დაადგინეს, რომ მონიტორინგის ქვეშ მყოფი გარემოების დაახლოებით 50%-ს ჰქონდა მინიმუმ ერთი მანქანა მინიმუმ ერთი პროცესით, რომელიც დამოკიდებულია OpenSSL-ის დაუცველ ვერსიაზე. არსებულიდან, ქსელში არსებული მანქანების  0.2%-დან 33%-მდე დამოკიდებული იყო  OpenSSL დაუცველ ვერსიაზე.

შესაბამის დეპარტამენტს მომდევნო ორი თვის განმავლობაში დიდი სამუშაოს შესრულება მოუწევს აღნიშნულის გამოსასწორებლად. (რატომ ხდება ეს ყოველთვის წლის ბოლოს?)

ჩავიხედოთ უფრო ღრმად CVE-2022-3602 -ში

სერვისის უარყოფის (DoS) შეტევის გარდა, ამ CVE შეიძლება გამოიწვიოს RCE. მოდით განვიხილოთ, როგორ მუშაობს ეს დაუცველობა დეტალურად. ამისათვის ჩვენ უნდა დავბრუნდეთ უკან და ვნახოთ როგორ დაიწყო ეს ყველაფერი.

კარგი, მაგრამ სად არის დეველოპერების შეცდომა, რამაც გამოიწვია ეს?

პროგრამისტებს აქვთ ხუმრობა, რომელიც ასე ჟღერს: „თუ კოდი მუშაობს, არ შეეხო მას!“, გარდა იმისა, რომ ამჯერად ჩვენ ამას ვიყენებთ უსაფრთხოების კონტექსტში. OpenSSL-ის დეველოპერებმა OpenSSL 3.0.0-ში შემოიღეს ახალი ფუნქცია სახელწოდებით ossl_punycode_decode, რომელიც უზრუნველყოფს punycode დომენური სახელების დეკოდირების ფუნქციონირებას.

ახლა, შეიძლება გაგიკვირდეთ, რა არის punycode და როგორ იწვევს ის ასეთ მაღალი რისკის დაუცველობას.

Punycode არის მარტივი და ეფექტური გადაცემის კოდირების სინტაქსი, რომელიც შექმნილია აპლიკაციებში ინტერნაციონალიზებული დომენის სახელებით (IDNA) გამოსაყენებლად. ის გარდაქმნის Unicode სტრიქონს ASCII სტრიქონად.

კომპიუტერები გარდაქმნის IDNA დომენებს Punycode დომენებად. OpenSSL-ში, osslpunycodedecode იღებს punycode დომენის ბუფერს სტრიქონის სახით და გადაჰყავს ის უნიკოდში დამატებითი დამუშავებისთვის.

ვინაიდან ეს დაუცველობა არის ბუფერის გადავსება, სადღაც მონაცემები გადის ბუფერის საზღვრებიდან და ხდება მეხსიერების მიმდებარე ლოკაციების გადაწერა.

CVE-2022-3602-ში ეს ხდება X.509 სერტიფიკატის ვერიფიკაციის დროს. კოდირების ეს დაუცველობა ჩნდება osslpunycodedecode ფუნქციაში, სადაც ის გამოიყენება Punycode დომენების უნიკოდად გადაქცევისთვის.

კოდირების ეს დაუცველობა თავდამსხმელს საშუალებას აძლევს მსხვერპლ მანქანაზე გაუშვას საკუთარი კოდი ხელმოწერილი მავნე TLS სერტიფიკატის გამოყენებით.

რეპოზიტორი დაუცველი ფუნქციით შეგიძლიათ ნახოთ აქ

 

 

მაშინაც კი, თუ თავდამსხმელი მოახერხებს ყველა სხვა წინაღობის გადალახვას, ის შეძლებს სტეკში მხოლოდ ერთი 4 ბაიტიანი ელემენტის ჩაწერას. ადრე ძირითადად ოთხი ბაიტი საკმარისი იყო სტეკზე დაბრუნების მაჩვენებლის ჩასანაცვლებლად და რენდომული კოდის შესასრულებლად, მაგრამ არა დღეს. ეს იმიტომ ხდება, რომ ამ შეტევის შეჩერება ადვილად შეუძლია ASLR და Canaries დაცვის საშუალებებს.

როგორ გავიგო დაუცველი ვარ თუ არა?

არსებობს რამდენიმე გზა, რომლითაც შეგიძლიათ გაარკვიოთ, იყენებს თუ არა თქვენი ეგზემპლარი დაუცველ ვერსიას. ჯერ უნდა იცოდეთ, რომ ამ CVE-ების მიმართ დაუცველია მხოლოდ OpenSSL 3.0.0-3.0.6 ვერსიები.

თუ თქვენი მანქანის ხელით შემოწმება გსურთ, მთელი რიგი ნაბიჯების გავლა მოგიწევთ, რათა დაადგინოთ, თუ რომელი OpenSSL ვერსიაა გაშვებული.

სისტემა

Linux-ის ოპერაციულ სისტემაში შემდეგი კოდის აკრეფით ნახავთ სისტემაში გაშვებულ OpenSSL ვერსიას. თუ ის არის 3.0.0-3.0.6 შორის, თქვენ რისკის ქვეშ ხართ და დაუყოვნებლივ უნდა განაახლოთ OpenSSL-ი.

openssl ვერსია

დინამიურად დაკავშირებული

შემდეგ, ჩვენ უნდა ჩაუღრმავდეთ და ეძიოთ დინამიურად დატვირთული პროცესები. ამის გაკეთება შეიძლება lsof ბრძანების გამოყენებით.

lsof | grep libssl.so.3

 

ასევე გთავაზობთ სკრიპტებს, რომლებიც გამოსადეგია გამოვლენაში

Linux და *Nix სკანერი (Bash Script): https://github.com/MalwareTech/SpookySSLTools/blob/main/openssl_scan.sh

Windows სკანერი (PowerShell): https://github.com/MalwareTech/SpookySSLTools/blob/main/openssl_scan.ps1

წყარო: www.malwaretech.com

სტატიკურად დაკავშირებული პროგრამული უზრუნველყოფა

ახლა მოდის ურთულესი ნაწილი, რადგან სტატიკურად შედგენილი პროგრამული უზრუნველყოფა lsof არ ამოიცნობს OpenSSL ვერსიებს და არც ამ სკრიპტებს. ამიტომ სტატიკურად შედგენილი პროგრამული უზრუნველყოფისთვის დაგჭირდებათ readelf ბრძანების გამოყენება.

readelf -a [binary] | grep -i osslpunycodedecode

ახლა მოდის უმძიმესი ნაწილი, სტატიკურად com-ისთვის კიდევ ერთი მეთოდი, რომელიც ჩვენ სასარგებლოდ მივიჩნიეთ, არის ქვემოთ მოცემული ექსპრესიის გამოყენება პირდაპირ ბინარულ ფაილზე:

Unix-like: strings /path/to/executable | grep “^OpenSSL\s*[0-9].[0-9].[0-9]”

Windows: select-string -Path C:\path\to\executable.exe -Pattern “OpenSSL\s*[0-9].[0-9].[0-9]” -AllMatches | % { $.Matches } | % { $.Value }

წყარო: malwaretech.com

როგორ მოვიქცე თუ დაუცველი ვარ?

თქვენი სისტემის გამოსწორება ძალიან მარტივია.OpenSSL ვერსიის განახლებით მარტივად შეძლებთ საფრთხის შემსუბუქებას.

მიჰყევით ამ ნაბიჯებს თქვენი OpenSSL ვერსიის 3.0.7-ით განახლებისთვის

wget https://www.openssl.org/source/openssl-3.0.7.tar.gz

chmod +x openssl-3.0.7.tar.gz

tar -zxf openssl-3.0.7.tar.gz

cd openssl-3.0.7/

./config

 

sudo apt install make gcc

sudo make

sudo make test

sudo mv /usr/bin/openssl ~/tmp

sudo make install

sudo ldconfig /usr/local/lib64/

sudo ln -s /usr/local/bin/openssl /usr/bin/openssl

sudo ldconfig

ამ ბრძანების გაშვების შემდეგ ჩვენ ვიღებთ OpenSSL 3.0.7 ვერსიას და ახლა ერთი ნაბიჯით ვუსწრებთ თავდამსხმელებს.

ექსპლუატაციის წინაპირობები

ახლა, როდესაც ჩვენ გავიგეთ, თუ როგორ უნდა შეცვალოთ ჩვენი სისტემა, ვნახოთ პირობები, რომლებიც გვჭირდება წარმატებული შეტევისთვის. წარმატებული შეტევის განსახორციელებლად ორი მნიშვნელოვანი პირობაა.

პირველი და ყველაზე მნიშვნელოვანი, თავდასხმა ეყრდნობა ან სერთიფიკაციის ცენტრ (CA), რათა მოაწეროს ხელი მავნე სერთიფიკატს, ან მომხმარებელმა უნდა გამოტოვოს გაფრთხილებები და აპლიკაცია, სათანადოდ არ შეამოწმებს სერტიფიკატს.

შემდეგ გამოჩნდება სტეკის განლაგება და დაცვა. თუ პირველი პირობა ვერ შესრულდება, ეს ორი ფაქტორი ადვილად გაანეიტრალებს საფრთხეს.

ზემოაღნიშნულიდან გამომდინარე, გარდა იმისა, რომ ეს შეტევები რთული და ძნელად განსახორციელებელია, CVE-2022-3602-ით  (RCE) კოდის დისტანციურად შესრულება ძალიან რთულია.

რამდენად შეშფოთებული უნდა იყოთ?

იმ ადამიანების წყალობით, რომლებიც მუშაობდნენ უსაფრთხოების გაუმჯობესებაზე, ახლა ჩვენ გვაქვს დაცვა (ASLR, NX სტეკი, სტეკის ქუქი-ფაილები), რომლებიც ართულებს და ძნელად მისაღწევს ხდის სტეკის გადასასვლელების ექსპლუატაციას. ასევე, იმის გათვალისწინებით, რომ ეს დაუცველობა კლიენტის მხარეს მდებარეობს, პირველ რიგში გაფრთხილებას მიიღებთ. ასე რომ, ეს CVE შესანიშნავია იმ მომხმარებლებისთვის, რომლებიც ყოველ შეტყობინებაზე აწკაპუნებენ “yes”-ს წინასწარ წაკითხვის გარეშე.

უპირველეს ყოვლისა არ უნდა არ უნდა უგულებელყოთ კითხვა და არ უნდა იფიქროთ, რომ თავდამსხმელისთვის ძალიან რთულია ამ CVE-ების გამოყენება. როგორც კი საშუალება გექნებათ უნდა გააკეთოთ უსაფრთხოების განახლება OpenSSL 3.0.7-ზე.

ხშირად დასმული კითხვები

Q: არის თუ არა ყველა OpenSSL ვერსია დაუცველი ამ დაუცველობის წინაშე?

პასუხი: არა, შეცდომები გაჩნდა, როდესაც Punycode-ის დეკოდირების ფუნქციის ნაწილი (ამჟამად გამოიყენება მხოლოდ სერთიფიკატებში ელ.ფოსტის მისამართის სახელების შეზღუდვების დასამუშავებლად X.509 ). ეს კოდი პირველად დაინერგა OpenSSL 3.0.0-ში. OpenSSL 1.0.2, 1.1.1 და სხვა ადრინდელი ვერსიებზე გავლენას არ ახდენს.

Q: მჭირდება თუ არა TLS სერვერის სერთიფიკატების შეცვლა?

A: TLS სერვერის სერთიფიკატების შეცვლა არ გჭირდებათ.

Q: არის თუ არა ეს დაუცველობა ისეთივე როგორიც Heartbleed?

პასუხი: არა, წინაპირობის გამო, რომ უნდა მოხდეს კლიენტის ან სერვერის კონფიგურირება, რათა დაადასტუროს მავნე ელ.ფოსტის მისამართი სერტიფიკატში.

Q: იყო თუ არა შესაძლებელი ამ დაუცველობის თავიდან აცილება ადრე?

პასუხი: დიახ. ეს დაუცველობა ადრეც შეიძლებოდა აღმოჩენილიყო.

Q: როგორ აფასებს CVSS ამ მოწყვლადობას?

პასუხი: ორივე CVE-ს მინიჭებული აქვს CVSS ქულა 7.5 (მაღალი).

დასკვნა

კიბერუსაფრთხოების საზოგადოების ბევრმა წარმომადგენელმა გააკრიტიკა, თუ OpenSSL-ის მიდგომა ამ დაუცველობასთან, ისინი გარკვეულ სტრესში აგდებენ მომხმარებლებს, ჯერ აცხადებენ, რომ ის კრიტიკულია და მოგვიანებით ამცირებენ მაღალ დონეს. ამ დაუცველობის წინასწარმა გასაჯაროებამ კომპანიებს მისცა დრო, მოემზადონ ყველაზე უარესისთვის და მოამზადონ თავიანთი კრიტიკული აქტივები სწრაფი გამოსწორებისთვის.