Практическо приложение на "Cyber Kill Chain"

Искам да благодаря на колегите от Advanced Security Operations Center (ASOC) на Telelink Business Services за съдействието при проведената експертиза на хакнатата система, която е главният герой в следващите редове.

През месец декември на 2018 г. в блога описах случай на хакната Linux система и акцентирах върху това, дали да се доверим на чужди логове, при условие, че тази информация лесно може да се фалшифицира. Тук отново ще разгледам успешната атака и ще я съпоставя с модела Cyber Kill Chain на Lockheed Martin. Разбира се целта е да се види кога и по какъв начин е било възможно да се прекъсне веригата на събитията, довели до компрометирането.

Cyber Kill Chain

Компанията Lockheed Martin едва ли е известна с модела Cyber Kill Chain. Много по-вероятно е да сте виждали изтребителя F-35, който също е потенциална цел на хакери, поради сложността и зависимостта от системата ALIS.

Нека да оставим настрани F-35 и да се върнем към Cyber Kill Chain. По същество това е абстрактен модел, част от Intelligence Driven Defense, целящ да определи злонамерените действия и лица и да ни защити от тях. Най-важната цел е да се дефинира какво трябва да извършат злонамерените лица за да постигнат своите (злонамерени) цели.

Тези седем етапа, позволяват да разкрием и разберем какви са действията, извършени от злонамерените лица (това е част от процеса на разузнаване). Важно е да отбележим, че една атака се счита за успешна, само ако са преминати всички шест етапа, преди да се достигне до последния, а именно "Action on Objectives".

По време на всеки един етап, атакуваната страна може да предприеме редица действие, чрез които да перкъсне веригата и по този начин да попречи на атаката. Например, ако разгледаме първата стъпка "Разузнаване", злонамерените лица е възможно да се опитат да открият e-mail адреси на служители на целта, както и профилите им в различни социални мрежи. Допълнително може да се проведе и сканиране на системите с цел да се разберат техните IP адреси, използваните операциони системи и най-вече какви услуги работят на тях. Противодействието на подобни действия (в частност сканирания) е сравнително трудно, но ако се преглеждат логовете на e-mail сървърите, ако се анализира поведението на потребителите от гледна точка на посещаваните от тях сайтове и ако персонала е запознат с потенциалните атаки ще е възможно да се вземат мерки, с които да се блокират адресите, извърщваши сканиранията и да се определят набелязани като целеви профили.

Тук трябва да се намеси и терминът "видимост", дефиниращ до каква степен администраторите и инженерите, свързани с киберсигурността могат да видят, разберат и оценят какво се случва в поддържаните от тях инфраструктури. Замислете се, дали в компанията, в която работите имате SOC? Разполагате ли с необходимите системи да анализирате типа на трафика, отклоненията от нормалните видове протокол и пакети, дали знаете какви потенциални уязвимости има на важите системи и как те се променят с времето? Имате ли начин да анализирате поведението на потребителите - какви програми използват, какви сайтове посещават, дали изпращат конфиденцални данни по неподсигурен начин? Да, това са много въпроси, на които много фирми и държавни институции отговарят с не, а това е значителен проблем. Няма да се отклонявам, но едно решение, което набира популярност през последните години е т.нар. "SOC as a Service" (ще видите, че това е един начин да се прекъсне веригата от разгледаната атака).

Как беше хакната Linux системата?

Получих e-mail от колега администратор от университета, където преподавам, в който имаше прикачени писма и логове от няколко ISP, в които се виждаше, че от IP адрес от AS на университета има целеви злонамерени действия към външни адреси (по-точно SSH атака, насочена към паролите и потребителите и извършена по метода на грубата сила).

Това беше ясна индикация, че е възможно да има зловреден код и това се потвърди от направените анализи.

Все пак, какво точно се е случило?

Разузнаване

Хакнатата система е стар Linux сървър, работещ под управлението на Ubuntu Server 17.10, на който се хостват няколко CMS портала. Конфигурираният IP е публичен, а достъпа до OpenSSH  не е филтриран (няма ограничение от кои адреси може да опита да се свърже и да изгради SSH сесия) . Това позволява чрез просто сканиране за отворени портове (например с nmap) да се получи информация, че портове 22, 53, 80 и 443 са отворени. Това се потвърждава и от бърза справка в Shodan.

Засичане на сканиране на отворените портове е сравнително трудно без специализирани инструменти като SIEM, които корелират трафичните потоци (netflow) и данните от логовете с цел да се открият злонамерени действия. Също така този тип системи значително подобряват видимостта над инфраструктурата, от гледна точка на киберсигурността. Алармите, генерирани от тях е възможно да се използват за отстраняване на проблема и предпазване от последващи действия (т.нар. Remediation). Липсата на подобно предупреждение не е позволило администраторите да предприемат предпазни мерки. В същото време не-филтрирания порт 22 също се явява проблем, свързан със сигурността.

Подготовка на инструменти

След като злонамереното лице (възможно е процесът да е автоматизиран - заразена система извършва действията без намеса на човек, но нека да приемем, че в описания случай стъпките са предприети от хакер) е открило отворения SSH порт са направения няколко заключения:

1. Операционната система е Linux, BSD, UNIX и много по-малко вероятно е тя да бъде Microsoft Windows. Разбира се, с помощта на nmap е възможно да се определи типа много по-точно, но това сканиране би довело до повече аларми при защитните системи.
2. Публичен адрес с отворен порт TCP:22 може да бъде honeypot.
3. Възможно е да се направи опит за достъп до системата чрез речникова атака, проверяваща комбинации от потребител и парола.
4. Успешно свързване е предпоставка за инсталиране на зловреден код или за засичане от honeypot.

В конкретната ситуация, целта е да се инсталира "cryptocurrency miner" или "копач" на криптовалута. Необходимите инструменти за целта са скриптове за атаката на потребителя и паролата, такива за изтегляне на желаната зловредна програма и нейното стартиране и за прикриване на следите.

Речниковата атака може да се извърши лесно чрез MSF, Hydra, Ncrack,  и други инструменти. Предполагам вече се запитвате, как ще бъде открит потребителя? Отговорът е прост - отново с "речник", съдържащ някои от най-често изполваните имена, например admin, administrator, root, webmaster и т.н. Разбира се, за този тип атака за всеки потребител трябва да се проверят всички пароли от втори речник и колкото е по-дълъг списъка с потребителите, толкова по-бавна ще е проверката.

От горният лог се вижда броя на неуспешните и една успешна SSH сесия за различни потребители. Именно това доказва и извършената речникова атака.

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

1. Преглед на логовете ще покаже множеството неуспешно опити за свързване към системата, последвани от успешен.
2. Ръчен анализ на журналните файлове (логове) не винаги е целесъобразен и тук отново SIEM система би генерирала аларми и инцидент(и) в зависимост от направените настройки.
3. Инсталирането на инструмент като fail2ban би дало възможност при няколко неуспешни опита за достъп да се блокира за определен интервал от време IP адреса на източника.

Инсталирането на fail2ban на хакнатата система би било лесно:

sudo apt install fail2ban
sudo cp /etc/fail2ban/fail2ban.conf /etc/fail2ban/fail2ban.local
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo systemctl start fail2ban
sudo systemctl enable fail2ban

Бих ви препоръчал в /etc/fail2ban/jail.local да добавите адреси, които няма да се блокират при надвишаване на лимита на неуспешните опити за логване (т.нар. whitelist).

Доставка на зловредния товар, експлоатиране и инсталиране

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

Добавени са ключове за автентикация през SSH, което от гледна точка на злонамерените лица значително улеснява последващия достъп до компрометираната машина.

Непосредствено след това има регистриранa нова SSH сесия от IP адрес 159.203.169.16. В home директорията на хакнатия потребител е създадена нова скрита папка с име .ttp. В нея са изтеглени няколко файла (последващ анализ показва, че става въпрос за "копач" на криптовалута).

Стартиран е скрипт, добавящ нова cron задача (job), а цялата конфигурация на зловредния софтуер е записана в ~/.ttp/a/config.txt. Данните за пула са описани в pools.txt.

Прикриването на следите е направено чрез изчистване на историята на командите за bash.

Добавянето на нова задача за cron може да създаде лог запис, който да бъде анализиран от SIEM система и да се генерира съответна аларма. По този начин действието ще бъде засечено сравнително бързо и ще се предприемат мерки.

Команди и контрол

Зловредният код от примера не имплементира C&C функционалност, а просто използва ресурсите на системата за "копаене" на криптовалута и за нови атаки през компрометираната машина.

Достигане на поставените цели

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

Възможно ли е било да се прекъсне Cyber Kill Chain преди този последен етап - да, а начините бяха описани по-горе.

"Lessons Learned"

Какви изводи може да си направим от описаната ситуация? Какво научихме и за какво да внимаваме?

1. Компрометираният акаунт е бил тестов и е имал зададена слаба парола, което е позволило чрез речников подход да бъде открита комбинацията от потребителско име и парола. Тук основната отговорност е на администраторите на системата, които не са премахнали акаунта след приключване на неговото приложение, както и, че са  позволили да се използва слаба парола. Трябва да се обърне внимание на "Change Management" процеса, ако има такъв.
2. Фактът, че за инцидента е научено от трета страна (изпратените писма от ISP) показва, че логовете не са били регулярно преглеждани.
3. Компрометираната система не се наблюдава от SIEM, което значително ограничава видимостта върху сигурността на инфраструктурата. Представете си, ако вместо "копача" на криптовалута беше инсталиран "ransomware"...
4. Изходящият трафик от мрежата на университета не се анализира за атаки към външни адреси, което отново е значителен пропуск.

Благодарности

Още веднъж искам да благодаря на Севгин Али и Илия Дафчев за съдействието, усилията, "кофата със сълзи" и безсънните нощи при анализа на инцидента и на зловредния код.