Одит на киберсигурността : Открийте най-известните уязвимости

В тази статия ще изброим различните уязвимости в сигурността, които могат да бъдат използвани в дадена инфраструктура. За да направим това, ще играем като консултанти по ИТ сигурност, които трябва да извършат одит на сигурността за напълно фалшива компания. Затова създадохме измислена инфраструктурна среда, съставена от виртуални машини, за да тестваме и предотвратяваме различните рискове.

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

Инструкции

Контекст

Компанията FAKESHOP току-що пусна в производство своя нов сайт за електронна търговия. Тази компания се състои от 2000 служители. Предлага хранителни продукти, налични в супермаркетите, а също и на новия си търговски сайт. FAKESHOP се свърза с нас, за да извършим одит на сигурността на тяхната вътрешна инфраструктура. Целта на този документ е да представи тестовете, които сме извършили, и да оцени последствията, които могат да имат различните уязвимости в сигурността, които изброихме, както и решенията, които могат да бъдат предоставени. За целта компанията ни предостави 3 сървъра.

Цел на теста за проникване

Тестът за проникване е операция, която се състои в тестване на компютърна система, мрежа или уеб приложение, за да се открият уязвимости. За да направят това, одитите, отговарящи за тестовете, ще възприемат подхода и позата на злонамерен нападател, във всички отношения подобни на тези на истински нападател. Тест за проникване с две цели:

• Оценете риска от хакване
• Определете начини за намаляване на тези рискове

Нашата цел е да идентифицираме услугите, които са изложени на вътрешните сървъри на компанията. Това ще ни позволи да имаме преглед на инфраструктурите на FAKESHOP. И също така да направим списък на всички технически уязвимости, които сме успели да идентифицираме на различните сървъри, предоставени ни.
Ние също така ще предоставим препоръки и най-добри практики, така че FAKESHOP да може да отстрани различните уязвимости в сигурността, открити като възможно най-бързо и ефективно.

Напомняне за периметъра

За да извършим този одит на сигурността, компанията FAKESHOP ни предостави 3 сървъра на следните адреси:

• 172.16.231.28 -› VM1: Съдържа apache сървър
• 172.16.231.60: -› VM2: Съдържа tomcat сървър
• 172.16.231.92: -› VM3 : Съдържа webmin сървър

Идентифицирани уязвимости

• SSH сървър 7.4p1 — Man-In-Middle (VM1)
• FTP сървър — root достъп (VM1)
• HTTP сървър — Достъп до акаунти на потребители и администратори (VM1)
• PHP Wrapper — Филтър (VM1)
• SQL инжектиране — информация за потребителя (VM1)
• XML инжектиране — XXE (VM1)
• NetBIOS сесия — SMB проникване (VM1)
• Публичен достъп — Tomcat (VM2)
• JSP инжектиране - Tomcat (VM2)
• Webmin — root достъп (VM3)

SSH сървър 7.4p1 — Man-In-Middle (VM1)

Описание на уязвимостта

Атаката Man-in-the-middle води до прихващане от трета страна на данни, преминаващи между различни потребители или особено сървър и потребител.

Критична оценка

Среден

Оценка на корекцията

слаб

Сценарий на експлоатация

Започнахме със сканиране на отворените портове с помощта на инструмента NMAP, открихме, че няколко порта са отворени, включително порт 22/tcp. Благодарение на това сканиране забелязахме също, че услугата, работеща на този порт, е SSH сървър и че е на версия 7.4p1. След известно проучване успяхме да видим, че тази версия е уязвима за атаки Man-In-Middle. Тази уязвимост е коригирана в следващите версии.

Свързани препоръки

Няма наличен пач за тази версия, затова препоръчваме да актуализирате версията на OpenSSH 7.4p1. С използването на fail2ban това също ще открие дали някой се опитва да наложи груба сила на SSH

FTP сървър — root достъп (VM1)

Описание на уязвимостта

С предоставеното сканиране на отворени портове на сървъра установихме, че порт 2121/tcp е отворен и използва FTP версия ProFTPD 1.3.5b. Този порт не е защитен и следователно е отворен в анонимен режим. Сървърът осигурява достъп до публичния и частния ключ на основния сървър и следователно осигурява достъп до частни файлове, които са незащитени.

Критична оценка

Критичен

Оценка на корекцията

Среден

Сценарий на експлоатация

• Сканирахме VM1 с NMAP
• Установихме, че FTP услугата е отворена. Затова решаваме да се свържем със следната връзка към FTP сървъра с Firefox или Edge

ftp://172.16.231.28:2121

• Веднъж на уеб страницата можем да видим, че имаме достъп до публичните и частните ключове на сървъра като root. В момента тази информация не е защитена.
• След това изтеглихме id_rsa ключовете, които намерихме, със следните команди

wget ftp://172.16.231:2121/id_rsa 
wget ftp://172.16.231:2121/id_rsa.pub

• С помощта на софтуера JohnTheRipper се опитахме да направим BruteForce частния ключ, който възстановихме. Започнахме, като изпълнихме следната команда.

python ssh2john.py id_rsa > id_rsa.hash

• Създадохме файл id_rsa.hash, след което го копирахме в папката JohnTheRipper с командата:

cp id_rsa.hash /opt/JohnTheRipper/run

• След това потърсихме в интернет списък с най-използваните пароли през последните години и създадохме файл test.txt, след което също поставихме този файл в /opt/JohnTheRipper/run с файла id_rsa.
• След това изпълнихме следните команди:

./john --wordlist=test.text id_rsa.hash 
./john --show id_rsa.hash

• Успяхме да дешифрираме паролата: футбол

• Като се върнем в папката, в която изтеглихме файла id_rsa, изпълняваме следната команда:

ssh -i id_rsa [email protected]

Сега сме влезли като root във виртуалната машина.

Свързани препоръки

Препоръчваме да използвате SFTP сървър за SSH трансфери или да използвате SSL сертификат като FTPS. Актуализирайте вашата версия на Linux, в нашия случай Debian, за да актуализирате Proftpd с новите пакети. Също така ви препоръчваме да използвате специална машина изключително за FTP, защото само тя ще бъде засегната по време на атака (първоначално). Също така би било подходящо да създадете FTP регистрационни файлове на машината и да ги дублирате на друга машина, защото в случай на успешна атака това ще ви позволи да разберете какво се е случило.

HTTP сървър — Достъп до акаунти на потребители и администратори (VM1)

Описание на уязвимостта

С отвореното сканиране на портове на предоставените сървъри открихме, че порт 80/tcp е отворен и използва nginx версия 1.10.3. Тази версия има няколко недостатъка, които са коригирани.

Критична оценка

Критичен

Оценка на корекцията

Среден

Сценарий на експлоатация

• Чрез анализиране на уеб проекта в директорията /var/www/html на виртуалната машина открихме файлinfo.php, така че решихме да го потърсим директно на уебсайта, поставен на нашия достъпен на URL адрес “http://172.16.231.28/info.php” и имахме достъп до конфигурацията на сървъра и различните версии на php и phpmyadmin.

• В уеб проекта видяхме и файл robot.txt. Затова решихме да анализираме следния път в уеб браузъра:

http://172.16.231.28/robot.txt

• Намерихме на тази страница следните две връзки към страници:

/2375cf0c9b26748dff4abab5b154bf52 
/test.php

• Решаваме директно да отидем на URL “http://172.16.231.28/test.php”, който връща грешка 404. Така че опитваме втория URL “http://172.16.231.28/2375cf0c9b26748dff4abab5b154bf52” и стигаме до страница, която изглежда е административния панел
• Решаваме да оставим администратора на панела настрана, за да анализираме малко повече директорията, до която имаме достъп благодарение на FTP грешката. Търсейки още малко, отидохме в папката /var/www/html/include, намерихме в тази папка файла config.php.
• Като анализираме изходния код на файла config.php, можем да видим критична уязвимост. Този файл съдържа информацията за свързване към базата данни в обикновен текст.

• Докато продължаваме да анализираме изходния код, откриваме други значителни недостатъци.

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

• Затова се върнахме на страницата за вход на сайта, предоставена ни, и с новата информация, която извлякохме, се опитваме да се свържем чрез узурпиране на самоличността на потребител.

• В базата данни на уеб магазина имахме достъп и до таблицата на сътрудниците, която е таблицата с цялата информация за хората, които могат да влязат в администраторския панел, която намерихме по-късно.
• Затова се върнахме на страницата за администратор на панела и се опитахме да влезем, като се представихме за администратор. Първият ни опит се провали, защото в таблицата на сътрудниците паролите са криптирани.
• Затова се опитахме да дешифрираме паролата на потребителя, използвайки този „уебсайт“.
• Манипулацията беше извършена успешно и с дешифрираната парола успяхме да се свържем с администратора на панела.

Свързани препоръки

Налични са корекции за отстраняване на този пропуск в сигурността. Функцията db_protect не разрешава всички SQLI тип атаки.

PHP Wrapper — Филтър

Описание на уязвимостта

Като анализирахме страницата info.php, открихме, че опцията allow_url_fopenе отворена. Поради това предоставеният ни уебсайт е уязвим на атаки с обвивка, като PHP филтри. Благодарение на PHP филтъра ще можем да възстановим изходния код на PHP файл директно чрез промяна на URL адреса на уебсайта.

Критична оценка

Среден

Оценка на корекцията

Среден

Сценарий на експлоатация

• Анализирайки уебсайта, открихме в структурата на URL адреса, че той използва PHP Wrapper.

• Като променихме URL адреса с помощта на BURP, добавихме php://. Затова променяме URL адреса, както следва:

http://172.16.231.28/?page=php://filter/read=convert.base64-encode/resource=include/pages/login

• Кодът се показва на уебсайта и е кодиран в base64, ние възстановяваме този текст и ще се опитаме да го декодираме.

• Отиваме на този уеб сайт и поставяме възстановения текст на уебсайта, като внимаваме да премахнем NOT_OK, който е в началото на текста.
• След като декриптирането приключи, установяваме, че имаме достъп до изходния код на уебсайта. Също така имаме достъп до информация за формуляра за влизане, както и до информация от базата данни. Тук намираме масата с клиенти.

Свързани препоръки

В конфигурацията на PHP трябва да промените allow_url_fopen, allow_url_include, open_basedirкоито са отворени и също така внимавайте, когато извиквате функции като include (), require(), include_once() и require_once(). Чрез предаване на конфигурацията на allow_url_include на Off, това ще блокира изпълнението на функциите file_exists, is_file и filesize. Това ще блокира неуспешните типове LFI.

SQL инжектиране — информация за потребителя

Описание на уязвимостта

На вашата уеб платформа разбрахме, че е възможно да инжектирате SQL във вашия URL адрес на страница от вашия сайт за електронна търговия. Поради това успяхме да възстановим потребителската информация.

Критична оценка

Критичен

Оценка на корекцията

Среден

Сценарий на експлоатация

• Посещавайки различните артикули, продавани в уеб интерфейса, забелязахме следния URL адрес.

“http://172.16.231.28/single.php?item_id=1”

• Затова заменихме „item_id=1“ с „item_id=0“. Така че имаме следния URL адрес:

“http://172.16.231.28/single.php?item_id=0”

• Прихванахме тази страница с BURP и опитахме SQL инжекция. Добавихме UNION към URL адреса на страницата и след няколко опита успяхме да извлечем идентификационните данни на потребителя.

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

• По същия начин успяхме да извлечем и информацията на администратор. Паролата е криптирана за администраторите

• Затова се опитахме да дешифрираме паролата на потребителя, използвайки този „уебсайт“.
• Манипулацията беше извършена успешно и с дешифрираната парола успяхме да се свържем с администратора на панела.

Свързани препоръки

За предотвратяване на SQL инжекции могат да бъдат приложени няколко техники. На първо място, силно се препоръчва използването на изрази по време на SQL конструкции, например PDO за PHP. Ако първата препоръка не може да бъде изпълнена, тогава може би може да се предпочете писането на съхранена процедура. Това ще помогне за предотвратяване на SQL атаки, тъй като атакуващият ще трябва да знае точния синтаксис и името на съхранената процедура, преди да може да я изпълни. И ако процедурата не позволява UPDATE или DELETE, тогава вашата база данни е защитена. И накрая, последната точка, от съществено значение е да се извърши тест за валидиране на въведените от потребителя данни за всеки формуляр. Това ще ви предпази от SQL инжекции чрез формуляри.

XML инжектиране — XEE(VM1)

Описание на уязвимостта

XXE атака или XXE инжекция е вид атака срещу приложение, което използва XML. Тази атака възниква, когато XML вход, съдържащ препратка към външен обект, се обработва от неправилно конфигуриран XML анализатор

Критична оценка

Критичен

Оценка на корекцията

слаб

Сценарий на експлоатация

• Отидохме до „Забравена парола?“ страница.

• Попълнихме имейл адрес и изпратихме заявката, като щракнете върху бутона „Вход“.
• Със софтуера BURP прихванахме направената заявка и видяхме, че има XML код.

• Променихме XML кода със следната информация:

“<?xml version=”1.0” encoding=”UTF-8”> <!DOCTYPE foo [<!ENTITY xxe SYSTEM “file:///etc/passwd”>]> <document> <email> &xxe; </email> </document>”

• Успяхме да извлечем цялата информация, която е във файла passwd

Свързани препоръки

За да се предотврати инжектирането на XML файлове, може да се въведе наистина ефективна мярка. Първо се уверете, че технологията, която използвате за анализиране на вашите XML файлове, не позволява достъп до външни обекти по подразбиране. Ако случаят е такъв, тогава ще трябва да използвате функциите, въведени от технологията, за да ги забраните. В повечето случаи тази функция приема булево значение, което ще промени тази забрана.

NetBIOS сесия и SMB проникване (VM1)

Описание на уязвимостта

След като анализирахме вашата мрежа с помощта на NMAP, забелязахме, че порт 139/tcp е отворен. Съответства на Windows Netbios сесии. Следователно успяхме да разпознаем машината, която използваше споделяне на пакети, и тествахме проникването върху нея.

Критична оценка

Среден

Оценка на корекцията

Среден

Сценарий на експлоатация

• Ние инсталираме пакета „nmblookup“, който ще ни позволи да можем да сканираме различните отворени сесии, налични на даден IP. използваме ли команда

nmblookup -A 172.16.231.28

• След няколко търсения в мрежата забелязваме, че данните ‹20›. съответства на сесия с данни за споделяне. Решаваме да го използваме. За да направим това, инсталираме клиентския пакет nbm. Този пакет ни позволява да можем да се свързваме към работната сесия от Debian машина. След това решаваме да променим конфигурационните файлове на Samba, за да можем да успеем с проникването.

• Накрая се свързваме с машината с помощта на команда numclient:

sudo smbclient -L 172.16.231.28

• Услугата ни казва парола, която да вмъкнем за идентификатора VM028\root, не е зададена парола. Накрая връзката е успешна.

Свързани препоръки

Съветваме ви първо да защитите своите портове с помощта на защитната стена и може би да настроите черен списък на вече известни злонамерени хора. Можете също да използвате VPN, което ще ви позволи да шифровате данните си или да използвате пароли, за да споделяте вашите файлове. И накрая, вие също имате възможност да използвате филтриране на MAC адреси, за да запазите системата си защитена и недостъпна през мрежата.

Публичен достъп — Tomcat (VM2)

Описание на уязвимостта

Успяхме да имаме публичен достъп до вашия сървър Tomcat, което ни позволи да извлечем идентификатор, списък с текущи услуги и информация за сървъра. За да направим това, използвахме NMAP, което ни позволи да открием, че вашият http порт 8080/tcp е отворен. След това отидохме там и анализирахме вашата сървърна архитектура.

Критична оценка

Среден

Оценка на корекцията

слаб

Сценарий на експлоатация

• След NMAP и откриването на отворен http порт, 8080/tcp, решаваме да отидем на съответния url. Пристигаме на страница за край на инсталацията на Tomcat сървър.

• След това се опитваме да се свържем с мениджъра и/или хост мениджъра, като използваме връзките в края на страницата за инсталиране. Отваря се поле за вход. След няколко опита и проучвания в мрежата откриваме идентификатора tomcat:tomcat. За съжаление тези идентификатори не дават достъп до мениджъра и/или мениджъра на хоста.

• Продължаваме да анализираме архитектурата на сървъра, както и неговата услуга: мениджър и най-накрая намираме два URL адреса, които са интересни за нас. URL адресът 172.16.231.60:8080/manager/text/Serverinfo ни позволява да извлечем информация за сървъра

• URL адресът 172.16.231.60:8080/manager/text/list ни позволява да извлечем ROOT идентификатор, както и услугите, работещи на сървъра.

Свързани препоръки

За този недостатък ви препоръчваме да дефинирате нови пароли за достъп до вашия Tomcat интерфейс, след като направите това, ви препоръчваме да управлявате правилно правата за достъп до вашите различни работещи Tomcat услуги.

JSP инжектиране - Tomcat (VM2)

Описание на уязвимостта

След като вашата архитектура бъде анализирана, ние решаваме да направим опит за проникване с JSP страница, написана на JAVA. Целта на тази JSP страница е да може да разположи уеб конзола на сървъра Tomcat, за да може да изпълнява UNIX команди. За да го разположим на сървъра Tomcat, ще използваме идентификаторите, намерени по-рано, както и команда Curl.

Критична оценка

Критичен

Оценка на корекцията

Среден

Сценарий на експлоатация

• Първо започваме да създаваме уеб конзолата, която след това ще бъде внедрена на сървъра. За да направим това, извършваме търсения в интернет и след това намираме Webshell, който променяме, както желаем.

• След като уеб конзолата е създадена, ние инсталираме пакета JAVA sdk, за да можем да създадем манифест на нашата JSP страница. След като пакетът е инсталиран, ние също инсталираме Curl, за да можем да разположим нашия JSP на сървъра Tomcat. След това пристъпваме към създаването на манифеста.

mkdir webshell 
cp index.jsp webshell 
cd webshell 
jar -cvf ../webshell.war *

• След като манифестът бъде създаден, ние ще го качим на сървъра. За да направим това, ние използваме Curl, както и идентификаторите, възстановени при втората грешка на тази машина.

sudo curl --upload-file ../webshell.war “http://tomcat:[email protected]:8080/manager/text/deploy?path=/foo”

• С тази команда уеб конзолата ще бъде инжектирана към сървъра tomcat на този URL адрес: “172.16.231.60:8080/foo”

• След като грешките на нашата уеб конзола бъдат коригирани, отиваме на URL адреса, съответстващ на изтеглянето на JSP файла. За нас ще бъде /foo. Така че можем да изпълняваме UNIX команди. Започваме с търсене в сървъра за информация, която може да бъде компрометираща. Пристигаме в папка, /lib/discover/. Това съдържа само XML файлове на потенциални клиенти със списъци. Папките/conf, /logs, /policy, /webappsи /work са празни.

Свързани препоръки

Съветваме ви да поемете сигурността на вашия сървър Tomcat, за да предотвратите проникване на JSP. Затова ви съветваме да го защитите с SecurityManager, присъстващ в Tomcat 8.

Webmin — root достъп (VM3)

Описание на уязвимостта

След сканиране на услугите с NMAP открихме, че порт 10000/tcp е отворен с услуга webmin miniserv 1.953.

Критична оценка

Среден

Оценка на корекцията

Среден

Сценарий на експлоатация

• Сканирахме портовете и услугите, налични на третата машина, предоставена ни, която работи на IP 173.16.231.92. Намираме HTTP услуга, която сме използвали.
• Влязохме в URL адреса „https://172.16.231.91:10000/“ и се озовахме на страница за вход на администратор на Webmin.

• След няколко основни опита за свързване успяхме да се свържем със сайта, използвайки Login: webmin и Password: webmin, които са идентификатори по подразбиране на Webmin.

• Вече имаме цялата подробна информация за VM3, предоставена от Webmin.
• Използвахме администраторския панел, за да създадем нов потребител с роля Root. Можем също да променим паролата на root акаунта.

• Вече можем да влезем като root във VM3.

Свързани препоръки

Използвайте силна парола с малки и главни букви, цифри и специални знаци, за да защитите сървъра. Защитете своя порт, като промените например порта по подразбиране.

Заключение

Вече сме готови 👏

Ако имате някакви въпроси. Моля, отзиви, за да можем да обсъждаме и да се подобряваме взаимно.

Можете да ме намерите в Github