w3af (Web Application Attack and Audit Framework) შეუძლია ბევრი სისუსტეების დადგენა ვებ პროგრამებში.

შესაძლოა სხვადასხვა კლასის სისუსტის მოძებნა:

  • პრობლემა ჰოსტინგზე (ბექდორი…)
  • კონფიგურირების დროს დაშვებული შეცდომა (directory listing, სათადარიგო ფაილთან ხელმიწვდომა)
  • პროგრამირების დროს დაშვებული შეცდომები

ამ ტიპის სისუსტეების მოსაძებნად w3af იყენებს სხვადასხვა პლუგინს. არსებობს 130 პლუგინი (XSS, SQLi, LFI/RFI, information leaking, bruteforce…).

w3af-ის გამოყენება შეიძლება ორ ნაირად, გრაფიკული ინტერფეისით ან კონსოლიდან, მისი სკრიპტინგი მხოლოდ კონსოლიდაანა შესაძლო.

არქიტექტურა

პროგრამის არქიტექტურა

w3af-ის არქიტექტურა არ არის დაყოფილი სხვადასხვა მოდულად:

  • სკანირებას კონფიგურირება (პროფილები, პლუგინები…);
  • crawl-ი webSpider პლუგინის მეშვეობოთ;
  • პროგრამაში მონაცემების შესვლის პუნქტების აღმოჩენა spiderMan პლუგინით;
  • ინფორმაციების მოძებნა (sitemap.xml, robots.txt…);
  • ბუგების მოძებნა აღმოჩენილ მონაცემების შესვლის პუნქტებში;
  • ბუგების ექსპლუატაცია
  • აღმოჩენილი სისუსტეების რეპორტინგი.

Crawl

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

  • სესიების მართვა (იდენტიფიკაციის გვერდი / საიტიდან გასვლის ბმული, ქუქიები)
  • ჯავასკრიპტის მეშვეობით DOM-ის დინამიკურად შეცვლა
  • URL-ების დინამიკურად გადარქმევა
  • არა სწორად დაწერილი HTML-ის ანალიზი
  • Captchas

ყურადღება: w3af-ს არა აქვს ჯავასკრიპტის და ფლეშის მხარდაჭერა. რახან crawl-ი (პლუგინი webSpider) არ არის სრულყოფილი შესაძლოა ლოკალური პროქსის გამოყენება, ამის საშუალებას იძლევა პლუგინი spiderMan, ამ პლუგინით შეგვიძლია დამიზნებული საიტის სხვადასხვა ვებგვერდს ვესტუმროთ რომ w3af-მა აღმოაჩინოს მონაცემების ინექციის წერტილები (მაგალითად იდენტიფიკაციის ფორმულების შევსება). როცა სწავლა/აღმოჩენა შესრულდა (ამას მომხმარებელი საზღვრავს) w3af უშვებს მომხმარებლის მიერ შერჩეულ პლუგინებს არმოჩენილი წერტილების წინააღმდეგ, ბრაუზერის კონფიგურირებაა საჭირო რომ ტრეფიკმა spiderMan პროქსით იმოძრაოს.

სესიების მართვა

w3af-ს აქვს ქუქიების მხარდაჭერა spiderMan პლუგინის დამსახურებით, ამიტო საინტერესოა მისი webSpider-ის ერთდროულად გამოყენება ისეთი ვებგვერდების აღმოსაჩენად რომლებსაც ქუქიების გარეშე ვერ მივწვებოდით. CookieJar-ის დამატება ჯერჯერობით შეუძლებელია (wapiti-ს და skipfish-ს შეუძლიათ). აგრეთვე შესაძლოა HTTP ავტორიზაცია (basic) მაგრამ ფორმულების ავტომატურად შევსება შეუძლებელია.

პროფილები

შეგვიძლია შევქმნათ სკანირების პროფილი რომელიც მხოლოდ არჩეულ ტესტირებას ჩაატარებს (მაგალითად მხოლოდ SQL-ინექციას) ამასთანავე დაზოგდება დრო.

პლუგინები

არსებობს სხვადასხვა კატეგორიის პლუგინები:

  • audit: სხვადასხვა კლასის სისუსტეების ძებმა (XSS, SQL-ინექცია, ბრძანებების ინექცია, …).
  • bruteforce: ავტორიზაციის გატეხვა ფორმულების მეშვეობით ან HTTP basic.
  • evasion: ისე ფუთავს გაგზავნილ მონაცემებს (რექვესტებს) რომ დამცველმა პროგრამა ვერ მიხვდეს რომ შეტევა მიმდინარეობს, სტელისა.
  • grep: ინფორმაციებს ეძენს ვებგვერდებში (კრედიტ კარტის ნომერი, …).
  • mangle: რექვესტების და პასუხების თანადროულად შეცვლა.
  • discovery: საიტიზე აგროვებს ინფორმაციას (captchas, ბექდორის არსებობა, საპროგრამო ფაირვოლის ანაბეჭდი, …).
  • output: რეზულტატებს ინახავს მრავალ სახეობაში (HTML, XML, ტექსტი, …).

მარგი ტვირთები ექსპლუატაციისთვის

მარგი ტვირთები მდებარეობენ პაპკაში რომელიცაა w3af/plugins/attack/payloads/payloads. შესაძლოა ექსპლოიტის ავტომატურად შექმნა მაგრამ თუ ვერ შეიქმნა ეს არ ნიშნავს რომ ექსპლოიტი ვერ შეიქმნება არამედ რომ ქლბათ “ხელით” უნდა შექმნათ.

ბუგების ძებნა

XSS ბუგების ძებნა

XSS ბუგების აღმოჩენა არის დაპროგრამებული plugins/xss.py და grep/domXss.py-ში. შემდგომ მაგალითებში მიგვაჩნია რომ w3af კონფიგურირებულია URL-ების შემოწმებისთვის თავიანთი “query string-ებით” რომლებიც შეიცავს მომხმარებლის პარამეტრებს.

Reflected-XSS / Stored-XSS ბუგები

xss.py პლუგინის მოქმედება არის შემდეგი:

  • ჰაზადულად შექმნილი ტექსტის ინექცია შერჩეული მონაცამთა შესვლის წერტილში;
  • ამ ტექსტის ძებნა ვებგვერდზე
  • თუ ეს ტექსტი აღმოჩდა ვებგვერდზე
    • წინასწარ შედგენილი დაშვებული სიმბოლოების სიიდან სიმბოლოების ძებნა: < > ' ();
    • წინასწარ შედგენილი XSS ბუგების სიის გამოყენებით ყოველივე ბუგის ცდა და დარწმუნება რომ ფილტრირებული სიმბოლოები არ იმყოფებიან;
    • XSS ბუგების ინექცია პარამეტრებში არა ფილტრირებული სიმბოლოების მიხედვით;
    • იმოწმება არის თუ არა ერთერთი ბუგი შედფენილ ვებგვერდზე;
    • თუ არის:
      • მაშინ ექსპლუატაცია შესაძლოა (შესაძლოა HTML ტეგების დასრულება იყოს საჭირო);
    • თუ არ არის:
      • მაშინ მხოლოდ Stored-XSS ბუგები შეიძლება ყოფილიყოს.

ყურადღება: ამ პლუგინს უჭირს დცვალადების ანალიზი შედგენილ ვებგვერდზე, მაგალითად სხვადასხვანაირად ახარისხებს ამიტომაც ზოგზოგი რეზულტატი იქნება ფილტრირებული, ბაქსლაში ექნება დამატებული ან ენკოდირებული იქნება, თან შესაძლოა ზოგი HTML ტეგი საერთოდ ამოაგდოს რეზულტატიდან. ამიტომაც თუ პლუგინ xss.py არ აირჩევთ შესაძლოა ბუგების აღმოჩენას აცდეთ. ამავე დროს ამ პლუგინს არ შეუძლია XSS ინექციის კონტექსტის მართვა (ამა თუ იმ ტეგების შორის იმყოფება), wapiti ამ კლასის ბუგების ექსპლუატაციისთვის უფრო კარგია რახან მას აქვს ინექციის კონტექსტის მართვის საშუალება. XSS ტესტირება შესაძლოა მონაცემთა ბაზას დაეტყოს და საჭირო გახდეს მისი გაწმენდა.

DOM-based XSS ბუგები

domXss.py პლუგინს ფუნქციონირება შემდეგია:

  • საანალიზო გვერდის ჩამოტვირთვა;
  • ეძებეს რაც შესაძლოა გამოყენებული იყოს XSS ბუგისთვის: document.URL, document.URLUnencoded, document.location, document.referrer, window.location და DOM-ის შესაცვლელი ფუნქციები document.write, document.writeln, document.execCommand, document.open, eval, window.execScript.

ეს მოდული შექნილია ამიტ კლეინის სტატიის მიხედვით.

ყურადღება: ამ პლუგინს ას პროცენტიანად არ უნდა ენდოთ, ზოგ ბუგს ვერ იჭერს, ხან ზოგს ვითომ იჭერს მაგრამ არმოჩდება რომ სინამდვილეშო ბუგი არ ყოფილა, ეს იმიტომ რომ DOM-based XSS ბუგების დადგენა რთულია. XMLHttpRequest-ის მოცემულმა მონაცემებმა შესაძლოა უშიშროება დაასუსტოს, მაგრამ ამ ტიპის პრობლემების დასადასტურებლად ვებ-პროგრამის წყარო კოდი უნდა შეისწავლოთ.

SQL-ინექცია

SQL-ინექციის დასადგენად სხვადასხვა ტექნიკა არის დაპროგრამებული plugins/sqli.py-ში და plugins/blindSqli.py-ში.

პლუგინის მოქმედება არის შემდეგი:

  • შესაძლო შეცდომების საყურადღებო ტექსტების სიის შექმნა (მაგალითად MySQL-ისთვის იქნება “You have an error in your SQL syntax”);
  • d'z”0 სიმბოლების ინექცია SQL შეცდომის გამოწვევისთვის არასწორი SQL რექვესტის გამო;
  • პლუგინი ნახულობს შექმნილ ვებგვერდზე არის თუ არა სიიდან ერთერთი შეცდომის საყურადღებო ტექსტი;
  • თუ საყურადღებო ტექსტი არმოჩდა მაშინ ისკვნება რომ ინექცია შესაძლოა.

ამ მეთოდმა რომ იმოქმედოს SQL-ლის კონფიგურაციაში უნდა დაშვებული იყოს შეცდომის დროს საყურადღებო ტექსტის ჩვენების უფლება.

Blind SQL-ინექცია

პირველი მეთოდი

პირველი მეთოდი ეყრდობა შედარება სწორე ვებგვერდის და არასრორ ვებგვერდის შორის რომელიც SQL შეცდომითაა შექმნილი (მაგრამ რომელიც ვებგვერდზე უჩინარია):

  • მონაცემთა შეტანის წერტილიად d'z”0 სიმბოლოების ინექცია;
  • ორიგინალი გვერდის და ინექციის შემდგომ შექმნილი გვერდის შედარება, ამ ეტაპზე გამოიყენება ორი სხვადასხვა ალგორითმი (მეთოდი _strinEq და _setIntersection);
  • თუ განსხვავებები აჭარბებს რაიმე დონეს (შესაძლოა ამ პარამეტრის შეცვლა) მაშინ ინექციის შესძლებლობა აღმოჩენილია.

ეს მეთოდი არ არის 100% ზუსტი იმიტომ რომ ვებგვერდი შესაძლოა შეიცვალოს არა მხოლოდ ინეექციის გამო.

მეორე მეთოდი

მეორე მეთოდი ეყრდნომა SQL რექვესტის შესრულების დროის დათვლას:

  • სიის შექმნა რომელიც მოიცავს სამ ინექციას ყოველოვე SQL მონაცემთა ბაზისთვის რომლების მხარდაჭარაა w3af-ში (MSSQL, MySQL, PostgreSQL), მათ შორის შედის რექვესტი რომლის შესრულაბას სჭირდება განსაზღვრული დრო (BENCHMARK-ი MySQL-ისთვის, waitfor-ი MSSQL-ისთვის, pg_sleep-ი PostgreSQL-ისთვის);
  • ყოველივე რექვესტის ინექცია მონაცემთა შეტანის წერტილიდან
  • დროის სხვაობის ანალიზი რექვესტების გაგზავნიდან ვებგვერდის შექმნამდე
  • თუ დრო აჭარბებს მოცემულ საზღვარს მაშინ ინექციის შესრულება შესაძლოა.

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

LFI/RFI ბუგების ძებნა

localFileInclude.py პლუგინის ფუნქციონირება შემდეგია:

  • ფაილებში მყოფი ინფორმაციის თარგების სიის შექმნა (“root:x:0:0:” /etc/passwd-ისთვის, “default=multi” boot.ini-სთვის);
  • შეცდომების მესიჯების სია (“Warning: file_get_contents”);
  • include-ისთვის შესაძლო ფაილების სიის შექმნა;
  • რექვესტების გაგზავნა (GET/POST) ყოველივე ფაილის სახელით და პასუხის მიღება;
  • თუ ფაილებში მყოფი ინფორმაციის თარგი იმყოფება პასუხში და ორიგინალურ პასუძში თარგი არ იმყოფებოდა მაშინ LFI ბუგი აღმოჩენილია თარგთან დაკავშირებით;
  • თუ თარგი არ იმყოფება:
    • წყარო კოდის არსებობის შემოწმება პასუხში (is_source_file());
    • ამოწმებს თუ არსებობს ჩასმის (include) შეცდომები პასუხში.

RFI ბუგების აღმოჩენის პროცედურა მსგავსია, განსხვავება იმაშია რომ შორეული რესურსები ემატება (include) HTTP პროტოკოლის მეშვეობით. remoteFileInclude.py თქვენს სისტემას უკავშირდება (რასაც შესაძლოა ფაირვოლის მიერ დაშვება დასჭირდეს) და აგრეთვე http://w3af.sourceforge.net/w3af/remoteFileInclude.html (კიდე კაი ამის გამორთვა შესაძლოა).

HTTP header-ერბით ინექციის შესრულება არ არის მხარდაჭერილი.

შემოწმების ავტომატიზაცია

w3af კონსოლოდან მოხმარება გვაძლევს ავტომატირების.

w3af>> plugins
w3af/plugins>>> output console,textFile
w3af/plugins>>> output config textFile
w3af/plugins/output/config:textFile>>> set fileName output.txt
w3af/plugins/output/config:textFile>>> set verbose True
w3af/plugins/output/config:textFile>>> back
w3af/plugins>>> audit osCommanding
w3af/plugins>>> back
w3af>>> target
w3af/config:target>>> set target http://site.com/page.php?value=test
w3af/config:target>>> back
w3af>>> start
Found 1 URLs and 1 different points of injection.
The list of URLs is:
- http://site.com/page.php
The list of fuzzable requests is:
- http://site.com/page.php | Method: GET | Parameters: (values="test")
OS Commanding was found at: "http://site.com/page.php", using HTTP method GET. The sent data was: "value=ping+-c+9+localhost". This vulnerability was found in the request with id 18.
Finished scanning process.

მაგალითი

კონსოლიდან

Backtrack-ში:

root@bt:/pentest/web/w3af# ./w3af_console 
w3af>>> target
w3af/config:target>>> set target http://www.site.com 
w3af/config:target>>> back
w3af>>> plugins
w3af/plugins>>> audit blindSqli sqli xss
w3af/plugins>>> back
w3af>>> start

გრაფიკული ინტერფეისი

root@bt:/pentest/web/w3af# ./w3af_gui

შეზღუდულობა

შემდეგი შეზღუდულობები ეხება ყოველივე ვებ სკანერს:

  • კომპლექსური საიტების crawl-ინგი რთულია.
  • ფუნქციონალური სისუსტეების დადგენა შეუძლებელია (მონაცემთა ბაზაში პაროლების დაშიფრების გარეშე შენახვა).
  • სცენარების შემოწმება რთულია (მაგალითად კალათაში პროდუქტის დამატება, ამოგდება, სხვა პროუცტის დამატება, შემდეგ ეტაპზე გადასვლა,…).
  • საიტისთვის შესაძლოა საშიში გახდეს ტესტირებების ჩატარება (SQL ინექცია DELETE-ით, Stored XSS,…).
  • ქსელური ტრეფიკის რაოდენობამ შესაძლოა ქსელი შეაფერხოს.
  • ვებსერვერის ჟურნალის ფაილის ზომა საგრძნობლად გაიზრდება.

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

ქსელი/http/w3af.txt · Last modified: 2012/07/15 14:52 by dzvelivereli
Back to top
Public Domain
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0